Lazer

Tu comptes le cache ou pas làdedans ? Car le cache a tendance àvarier plus que la mémoire réellement utilisée

Arf OK merci de la précision, j'avais zappé qu'il y avait PRO et PRO+

Les modules sur piles sont déclarés mort bien après leur mort effective. Comme il n'y a pas de polling (puisque le module est endormi), alors la HC2 ne peut pas savoir si le module est effectivement mort. J'ai systématiquement constaté plusieurs jours sans signe de vie avant qu'elle les déclare mort. Bon j'ai pas encore eu de piles de FGMS à changer

yes je suis bien d'accord. Néanmoins en v3, j'avais des nÅ“uds morts, un peu incompréhensibles (même si c'était souvent les 3/4 mêmes qui revenaient), alors que ça a subitement disparu lors du passage en v4 (sans ajouter de module à ce moment là ). Dans ce cas là , le diagnostique aurait pu être utile. Mais c'est surtout pour ceux qui ont des problèmes de latence, ou je pense également à Hansolo il y a peu de temps, que ça pourrait être utile. Bref, c'est pas la fonction la plus indispensable qu'on attend sur HC2, mais ça serait sympa quand même. Plus sympa qu'un panneau de notifications à 2 balles qui te signales que tu n'as pas de template pour des modules dont FIbaro NE VEUT PAS fournir les templates

Tout pareil que Jojo En v4 on a un moteur Z-Wave bien stable (*), ce n'est plus indispensable. (*) => visiblement quelques uns ont quand même de problèmes de latence, ou d'instabilité dà» à un module en particulier, dans ces rares cas, un panneau de diagnostique serait bien utile. Faut voir la quantité d'information affichée par OpenZwave, c'est assez intéressant, j'imagine que sur un réseau conséquent on doit avoir quelques surprises. Il ne se contente pas d'afficher la table de routage, mais également plein de statistiques pour chaque module, on peut voir le plus bavard, le plus mauvais temps de réponse, etc.... ainsi on peut détecter les mauvais élèves et maintenir son réseau toujours au top. Bon ça c'est pour la théorie, comme dis ce matin, je n'ai pas d'expérience, et j'ai vu très peu de retour d'expérience, sur des réseau conséquents (>50 modules) avec Jeedom. Et il n'y a pas que la latence du réseau Z-Wave qui compte, il y a aussi le CPU dans la machine pour interpréter les résultats.... de ce coté là le Raspberry est insuffisant, ceux qui ont des installations conséquentes ne laissent que le moteur Z-Wave sur le RPI et déportent l’intelligence sur un PC. Et c'est là qu'on se dit qu'une Jeedom Center boostée aux hormones manque cruellement. Ce qui est bête, c'est qu'il me semble qu'aux dernières nouvelles, la Jeedom Center sera moins puissante que la Jeedom Pro, c'est dommage de segmenter ainsi.

@Jojo en a parlé, mais je ne retrouve pas où.

oui la migration c'est toujours quelque chose de délicat, que ça soit jeedom ou tout autre système informatique. Par contre l'install d'une nouvelle v2, comme je l'ai fait, est franchement facile. Ca se passe exactement comme décrit dans la doc officielle, même pas besoin de comprendre ce qu'on fait. PS : moi je n'ai aucun souci de retour d'état en 4.071b Juste des VD/ scène qui core-dump de temps en temps, mais on serait presque habitué et mon watchdog veille au grain

Je l'avais testé en 2014 et maintenant en 2016, c'est sûr que côté interface ça n'a pas du tout évolué. Par contre ils ne ciblent pas du tout le grand public. Une communauté de geek, et un business modèle orienté vers les pro (avec le cursus de formation obligatoire). Est ce que ça fonctionnera est une autre histoire. Ceci dit, quand je vois le travail accompli en moins de temps que Fibaro avec une équipe aussi réduire, je me dis qu'il y a quand même un gros potentiel.... Suffirait juste qu'ils embauchent un designer, et qu'ils arrivent àsortir une vraie box, pas un espèce de Raspberry amélioré. Par contre je manque de recul sur la stabilité du moteur Z-Wave avec une grosse installation. C'est un point important.

Ca m'a pris une grosse heure (en faisant autre chose en //) pour installer Jeedom from scratch. Les 3 grandes étapes : - création d'une VM et installation minimale de Debian 8.3 - copie/coller des commandes fournies dans la doc de Jeedom pour installer Jeedom - connexion au market, installation de OpenZwave Bon j'ai affecté à la VM 4 cores Xeon et un SSD, ça aide. J'imagine que sur une machine moins puissante, ça prendra un peu plus de temps. L'avantage, c'est que j'ai une vraie VM totalement indépendante, que je peux migrer sur n'importe quelle autre machine. C'est autre chose qu'un docker

hum, pas testé ces modules en particulier. le Shutter 24V, c'est pour les velux ? Il fonctionne ou pas maintenant ?

franchement, depuis la dernière fois que j'ai testé, ça a bien évolué. Bon l'interface est ce qu'elle est, mais une fois qu'on a compris ça va vite, on trouve ce qu'on veut, et y'a tellement d'options pour diagnostiquer le Z-Wave, rien que pour ça c'est fabuleux Par contre, l'interface utilisateur, les widgets et icônes fournies de base..... comment dire.... c'est hideux !!! oui comme tu dis, pas d'appli smartphone, il parait que ça va venir.

oh le fourbe, il a mis àjour son profil

m'en fous, je fais mumuse avec jeedom

4.071 beta aucun problème pour ma part, ça semble stable, plus que la 4.070 inclusion/exclusion, reconfiguration de module, remonté des infos, j'ai pas eu de souci sur mes 2 HC2 t'aurais pas homebridge par hasard ?

Oui j'ai pris chez Domadoo aussi. Je vais les contacter également.....

Je crois que je commence à comprendre un truc : Dans les paramètres du module, on peut activer les Actions ON et OFF (cachées par défaut) Donc sur le dashboard, on voit apparaitre 2 boutons On/Off => cela commande bien la lumière, cette fois ci ça s'allume et ça s'éteint. Par contre ça prend toujours en compte le paramètre 66 (3s), sont le soft start&stop est long..... Et les latences sont toujours présentes. Bref, Jeedom affiche beaucoup plus d'infos que HC2, ça c'est sympa. Mais le comportement du module n'est toujours pas satisfaisant de mon point de vue..... les bon vieux FGD-211 ont encore de beaux jours devant eux.

voilà

Bon bah ce module n'est pas brillant (huhu...) sous Jeedom. obligé de débrancher/rebrancher le module pour arriver à l'inclure => idem HC2 latence importante (1 à 2 secondes) de la remonté d'information vers Jeedom (valeur du dimmer, et mesure de consommation) => idem HC2 depuis Jeedom, lorsque je demande éteindre la lumière, le soft-stop met 3 secondes (à cause du paramètre 66), tandis que la commande locale depuis le poussoir fait bien un soft-stop en 1s => idem HC2 depuis Jeedom, impossible d'allumer la lumière (que ce soit à 100%, ou une valeur intermédiaire) !!! => pire que HC2 Bref, selon mon test, ce module fonctionne encore plus mal avec Jeedom que HC2 (à cause de l'allumage impossible) Vu les différents tests menés hier et aujourd'hui, j'en déduis que c'est le firmware du module qui en est responsable : latences de remonté d'information soft start/stop depuis le contrôleur (quand ils veulent bien fonctionner) qui prennent en compte le paramètre 66 (3s) avec que c'est le paramètre 65 qui devrait s'appliquer (1s) => la conséquence de ça, c'est que le module est inutilisable avec des lampes non-dimmables (LED, Fluocompacte), car la valeur mini à 1s provoque inévitablement des flashs et une usure prématurée de la lampe. Je n'ai pas d'autre dimmer Qubino pour comparer ces dysfonctionnements. Par contre, j'ai 4 Qubino Fil Pilote de 1ère génération (Z-Wave standard), qui sont donc des dimmers, et qui remontent immédiatement l'information à la HC2. J'en conclus que ce nouveau Dimmer DIN Z-Wave+ ZMNHSD1 a un sacré problème. Quelque chose me dit qu'ils vont vite repartir d'où ils viennent. J'ai pas pour habitude d'utiliser mon droit de rétractation auprès des boutiques, mais là je suis très déçu Au passage, coup de gueule contre les vendeurs domotiques, qui ne communiquent pas sur ces problèmes, alors qu'on est au moins 3 sur ce forum a rencontrer des soucis (ce qui doit représenter 100% des testeurs, car il ne me semble pas avoir vu d'autres retours que PITP2, i-magin, et moi)

A noter qu'il reste un souci avec le code précédent.... en fait ce n'est pas la faute du code LUA, mais la faut de l'appli SMS Gateway sur le téléphone Android. Si le smartphone a rebooté et que la SIM n'est pas déverrouillée avec le PIN code, alors le téléphone n'accroche pas le réseau GSM. Jusque là c'est normal. Par contre, l'appli SMS Gateway renvoie quand même la réponse "Mesage SENT!", donc le code LUA pense que le SMS est parti, alors qu'en fait il ne partira jamais. Je n'ai pas encore trouvé de solution de contournement.... je pense que ça va se terminer que je vais supprimer le PIN code de la carte SIM, comme ça en cas de reboot du téléphone, il devrait accrocher le réseau GSM tout seul. Finalement la question qu'on peut se poser, c'est pourquoi le téléphone reboote tout seul ? J'en sais trop rien, mais c'est un vieil HTC Desire HD, qui était sous Android 2.x officiellement, j'ai dà» passer sur une version non officielle de CyanogemMod pour avoir Android 4.2 qui supporte SMS Gateway et Tasker. Je dirais qu'il reboote tout seul en moyenne une fois tous les 3 mois.... la dernière fois qu'il m'a fait le coup c'était le lendemain de notre départ en vacances ! Les boules

Chez moi, ça ne fonctionne pas de temps en temps à cause du Wi-Fi qui est instable.... c'est pour ça qu'un 2nd appui suffit généralement, quelques secondes ou minutes plus tard. Je te propose le code optimisé ci-dessous : -- User configurable variables local password = "password" local numero = "0123456789" local userID = 4 -- Email local smartphoneID = 411 -- Push local retry_max = 6 local retry_sleep = 10 -- System variables local selfID = fibaro:getSelfId() local ip = fibaro:get(selfID, 'IPAddress') local port = fibaro:get(selfID, 'TCPPort') local message = fibaro:getGlobalValue("SMS") local erreur = 0 -- URL Encode function function urlencode(str) if (str) then str = string.gsub (str, "\n", "\r\n") str = string.gsub (str, "([^%w %-%_%.%~])", function (c) return string.format ("%%%02X", string.byte(c)) end) str = string.gsub (str, " ", "+") end return str end -- Main fibaro:call(selfID, "setProperty", "ui.LabelStatus.value", "...") fibaro:debug(os.date("%d/%m/%Y")) fibaro:call(selfID, "setProperty", "ui.LabelSMS.value", message) local server = Net.FHttp(ip, tonumber(port)) local payload = "/sendsms?phone="..numero.."&text="..urlencode(tostring(message or "empty")).."&password="..password fibaro:debug(message) for i=1, retry_max do response, status, errorCode = server:GET(payload) if tonumber(errorCode) == 0 and tonumber(status) == 200 then if (response ~= nil) then if response:match("Mesage SENT!") then fibaro:debug(response) fibaro:call(selfID, "setProperty", "ui.LabelStatus.value", "SMS envoyé") fibaro:log("SMS envoyé") erreur = 0 break else fibaro:debug("Error : incorrect response") fibaro:debug('<span style="color:red;">status='..status..', errorCode='..errorCode..', response='..response..'</span>') erreur = erreur + 1 end else fibaro:debug("Error : empty response") fibaro:debug('<span style="color:red;">status='..status..', errorCode='..errorCode..'</span>') erreur = erreur + 1 end else fibaro:debug("Error !") fibaro:debug('<span style="color:red;">status='..status..', errorCode='..errorCode..', response='..response..'</span>') erreur = erreur + 1 end fibaro:sleep(retry_sleep*1000) end -- Error management if erreur > 0 then fibaro:call(selfID, "setProperty", "ui.LabelStatus.value", "SMS non envoyé") fibaro:log("Error") fibaro:call(smartphoneID, "sendPush", "Erreur lors de l'envoi du SMS") fibaro:call(userID, "sendEmail", "SMS Gateway", "Erreur lors de l'envoi du SMS : "..message) end -- Reset global variable value fibaro:setGlobal("SMS", "")

@Fredric, j'ai raccroché ta question au topic d'origine

Pré-alarme faible, déclenchement immédiat.

Mon Jeedom est prêt, mais je ferai le test plus tard, j'ai ma fille dans les pattes, c'est pas idéal pour le 220V. Intéressant ton retour i-magin, donc le module se comporte exactement pareil sous Jeedom que HC2.... donc le problème vient du module visiblement Pour le coup, j'aurais préféré que les bugs soient dans la HC2.... @PITP2 oui ça serait pas mal si Qubino pouvait communiquer, visiblement leur module est loin d'être parfait. J'ai plusieurs fois entendu dire que leurs firmwares sont buggés, ça semble se confirmer....

Je vais essayer de m'installer une Debian + Jeedom en VM ce week-end, avec une clé Z-Wave en stock pour voir ce qu'il en est.

normal ton pb i-magin, si 66 = 1 seconde, alors le controle depuis la HC2 fait dimmer la lampe.... donc sur une LED non dimmable, ça flashe, et ça risque de l'user prématurément. Reste à savoir si c'est un bug Qubino ou Fibaro... @PITP2 faudrait que tu testes sur Lifedomus pour voir le comportement ?!?