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à!