guchtpi

Bonjour tout le monde. Pensez-vous qu'il soit possible d'utiliser ce type de batterie: http://www.amazon.fr/gp/product/B0109S1UB0?psc=1&redirect=true&ref_=ox_sc_act_title_2&smid=A3EB5CTHC52I8Z en lieu et place des piles CR123A ... la tension de service est de 3,7V au lieu de 3,0V ... je sais qu'il y a en principe une tolérance sur la tension d'alimentation, mais là ça fait quand même presque 20% Quelqu'un a-t'il déjà essayé ? Merci. Pierre.

Oui, c'est une habitude à prendre ... mais ça en faut la peine (Grrrr... j'ai des problèmes avec les balises de code !)

Salut ... Et bein, c'est bien, tu commences à métriser tout ça :-) ! Si je puis me permettre une petite remarque de développeur... essayes d'utiliser des définitions de constantes (même si LUA ne possède pas vraiment ce concept) dans tes scripts, ça facilite la lisibilité et la portabilité du code. Par exemple: à la place de "132", tu déclares au début du code (en dehors des boucles et tests): LED_TV_ID = 132; (Ici, la "naming convention" consiste à mettre les noms des constantes en MAJUSCULES). Tu peux ensuite t'en servir dans les commandes du type: local light1 = fibaro:getValue(LED_TV_ID, "value"); fibaro:call(LED_TV_ID, "turnOn"); Ca n'a l'air de rien, et ça demande un peu plus de rigeur, mais je peux te garantir que ça clarrifie grandement le code... parfois, même pas besoin de mettre de commentaires :-)

@moicphil: Je ne comprends pas bien cette philosophie ... quand plusieurs personnes interviennent dans un fil c'est plus simple et plus clair de citer le passage que l'on veut commenter... tu ne trouves pas ?

@Shad: Pendant qq années j'étais développeur Java (applications Web essentiellement sous Weblogic), ensuite "Project Manager" ... mais trop de papier, j'ai pas aimé ! Maintenant disons que je suis 'Déployeur d'applications' ... en gros: réception des codes des contractant, intégration et installation des applications (toujours Weblogic/Java/Oracle DB) dans notre 'DataCenter' au Lux.

Oui, oui, je sais ... c'était pas des critiques, juste de la déformation professionnelle (j'suis informaticien !)

Ou un seul en dehors du dernier bloc if... end

Il y a peut-être aussi un autre soucis ... ça n'allumera les lumières que pendant le 'jour' et ne les éteindra que pendant la 'nuit' ... Oui mais ... et si on allume la TV pendant la nuit ? Ou si on l'éteind le jour suivant (au matin par exemple). C'est pas plutôt l'inverse qu'il faut tester dans le premier IF, comme ceci: fibaro:getGlobalValue("Jour_Nuit") == "Nuit" ) Et sortir la partie de détection de la basse consommation du test "nuit_jour", comme ça même si la TV est éteinte le jour suivant, les lampes suivront. Pour éviter le changement trop rapide, peut-être rajouter un sleep() de qcq secondes ... C'est juste qcq idées comme ça

@Shad: Si comme le dit lolomail, aucun message n'apparait, c'est qu'il y a clairement un problème avec ton premier test: if ((sourceTrigger['type']=='property') and ( fibaro:getGlobalValue("Jour_Nuit") == "Jour" )) then D'alleurs, à quoi sert exactement la première expression ?

Sinon, tu vires le test 'Jour/Nuit' pour l'instant, histoire d'isoler les problèmes ...

Oui ... revenons au vrai problème ! Si j'ai bien compris ... les LEDs s'allument correctement avec la TV mais ne s'éteignent pas ... Ne serait-ce pas à cause de ce test ... qui n'est TRUE que pendant la journée ... donc le soir ou la nuit ... bein ... le reste du code n'est plus exécuté ... if ((sourceTrigger['type']=='property') and ( fibaro:getGlobalValue("Jour_Nuit") == "Jour" )) then

Je cite wikipedia: Le protocole radio Z-Wave est optimisé pour des échanges à faible bande passante (entre 9 et 40 kbps) et des appareils sur pile ou alimentés électriquement, par opposition au Wi-Fi par exemple, qui est prévu pour des échanges à haut débit et sur des appareils alimentés électriquement uniquement. Donc, bande passante minimum: 9kps ... faut déjà pas mal de modules pour 'overloader' le réseau, même à 1 commande par seconde et par module ...

@I-magin: Mouis... d'accord, je comprend le principe (bien qu'au niveau strictement programmatique, ça n'a aucun sens :-) ! ) ... par contre, ce n'est pas très rassurant quand à la robustesse de la HC ... si 4 commandes en 10s (inutiles ou pas) peuvent la 'planter' ... bof bof bof ... Mais merci pour l'info.

Euh ... je suis peut être un peu con ... mais à quoi servent les tests sur les modules 132 et 133 ? Pas besoin de connaitre leurs états initiaux... on les allume ... ou on les éteint ... non ? Donc... en simplifiant, on obtient: --[[ %% properties 66 value %% globals --]] local sourceTrigger = fibaro:getSourceTrigger(); local current_conso = 0; local wallplug = 66; if ((sourceTrigger['type']=='property') and ( fibaro:getGlobalValue("Jour_Nuit") == "Jour" )) then if (startSource['deviceID']==tostring(wallplug)) then local current_conso = tonumber(fibaro:getValue(66, "valueSensor")); fibaro:debug("Conso wallplug " ..current_conso); if (current_conso > 80) then fibaro:debug(os.date() .. " - Télé allumée"); fibaro:debug(os.date() .. " - LEDs allumées"); fibaro:call(132, "turnOn"); fibaro:call(133, "turnOn"); else fibaro:debug(os.date() .. " - Télévision éteinte"); fibaro:debug(os.date() .. " - LEDs éteintes"); fibaro:call(132, "turnOff"); fibaro:call(133, "turnOff"); end end fibaro:sleep(10*1000) end

Argggghhhhh oui .... ce type est balaise en programmation ... le code faut la peine d'être bien analysé, il y a plein d'astuces ... dommage d'ailleurs que la doc Fibaro fasse un peu défaut sur ce plan là!

Bonjour à tous, Pour suivre un peu le fil, j'ai bien reçu le betit bornier dans le sachet ... mais ce qui m'amène c'est surtout la question de la consommation... quelqu'un a-t'il une expérience de plus de 5j ? (c'est le temps qu'on mis 2 piles différentes pour rendre l'âme !!! ... et avec les paramètres par défaut). Merci.

Bon bein, ça devient plus clair ... je viens de tester mon module ... batterie à 2,27V au lieu des 3V ... et ça au bout de 4j seulement, il y a donc clairement un problème avec ce module !!! Pas génial Fibaro

Je suis perplexe ... J'avais implémenté les scripts d'origine il y a quelques semaines. J'ai ensuite ajouté un capteur FGFS101 au réseau et au bout d'environ 1 semaine la batterie de celui-çi était vide, à noter que le module a été configuré avec les valeurs par défaut. Dans la doc: "Fibaro Smoke Sensor’s battery life is approximately 3 years when on optimum settings." ... donc problème ! Depuis ce w-e, j'ai désactivé les scripts de capture et remis une nouvelle batterie dans le FGFS101 ... wait and see ... si dans 1 semaine la batterie est de nouveau à plat, le problème sera à chercher dans les paramètres... Dans le doute, ce qui pourrait être utile, ce serait d'avoir une liste d'exclusion (par exemple dans une variable globale) pour certains ID.

Euh... oui mais faut faire attention si tu interroges un periphérique qui mesure la température et qui est sur batterie (comme le capteur FGFS101 Flood Sensor) !

Salut, Tu devrais jeter un petit coup d'oeil ici : http://forum.fibaro.com/viewtopic.php?t=2380&highlight=synology

Mmmm ... oui tu as raison, ce que je voulais dire: Protocole non lié à un seul fournisseur ! Et en particulier c'est ceci que je trouve important: "Plus de 100 fabricants utilisent cette technologie. Les fabricants sont regroupés au sein de l'Alliance Z-Wave. Les produits doivent être certifiés pour garantir leur interopérabilité. L'alliance a annoncé en 2012 que 700 périphériques avaient été certifiés." @+ Pierre.

Tout d'abord, je vous souhaite une très Bonne Année 2014 Alors voilà ... qui donc suis-je ? - Pierre - Belge (c'est pas une maladie ;-) ) - 49 ans (aie, là ça commence à compter !) - Ingénieur en électonique de formation (Pfff ... à l'époque des transistors ... si si !!!) - Informaticien de profession (Java, Web, Oracle RDBMS et autres joyeusetés du même genre) - Passionné de modélisme ('drones' MK et DJI Phantom), astronomie, photographie ... et domotique depuis toujours (merci Star Trek !) - En manque de temps permanent. Bon clairement, après avoir accumulé pas mal de systèmes (X10, prise domotique radiocommandées, modules Chacon, Box MyFox, etc...), je me suis plus particulièrement intéressé au protocol Z-Wave (pour son côté 'non-propriétaire') et je possède déjà quelques modules comme par exemple: - Contrôleur Z-Stick S2 Z-wave - Multisensor Z-Wave d'Aeon Labs - Wall Plug Fibaro - Capteur d'inondation Z-wave Fibaro - Micromodule Fibaro RGBW - Micromodule Fibaro FGS211 J'ai aussi testé avec plus ou moins de bonheur quelques solutions logicielles: - zVirtualScenes - Homidom - OpenSource Automation - Home Genie Et finallement opté pour SynoZwave ... puisque je possède un NAS Synology Bon, ça marche ... mais comme le produit est encore en Beta, c'est pas encore le top ... Donc, je me suis décidé à acquérir un controlleur dédié. En passant, une bonne page pour comparer ce trouve ici: http://socialcompare.com/fr/w/comparatif-box-domotique-11qzjci6 Après avoir hésité entre la ZiBase qui aurait pu convenir parfaitement et en plus permettre de réutiliser mes modules Chacon, mais le fait de devoir absolument dépendre d'une firme (qui peut tomber en faillite !) et de son site web pour faire fonctionner des scénari ne me plait pas du tout ! La décision d'achat de la solution Fibaro HC2 était donc plus facile (malgrè son prix élevé... mais bon elle sort visiblement du lot !) Reste plus qu'a passer la commande, ce que je fait faire dans les jours qui suivent... Voilà voilà @+ Pierre