Fredmas

Super @Sowliny Comme tu l'as vu, ce topic est plus à considérer comme un café philo du débutant passionné que du "faites-le pour moi" svp C'est d'ailleurs pour ça que nous poussons parfois certaines discussions/compréhension En tout cas grâce à ce topic et les membres, partant de zéro en QA (et en LUA) cela m'a permis de progresser tout en comprenant ce que je faisais afin d'être autonome en maintenance et évolutions. Et si ça t'intéresse de savoir (sinon c'est pareil puisque tu ne peux pas me répondre ), désormais je n'ai plus de variables globales (dans l'onglet Fibaro/Paramètres/Général/Variables), je n'ai plus de scènes (enfin une ou deux mais que pour Siri sur iPhone), uniquement des QA et quasiment aucune variable persistante dans l'onglet des QA. Un QA (qui évolue sans arrêt) pour gérer les automatismes principaux de la maison. Un QA météo (multi-météo puisqu'il fonctionne avec WeatherBit et OpenWeather avec un bouton pour choisir) pour récolter des informations envoyées aux autres QA pour des modifications d'automatismes. Un QA que je démarre pour gérer les extérieurs et la piscine. Un QA annexe probablement pour les trucs à venir, qui ne sont pas indispensables et qui me permettra de jouer sans crasher le reste qui est stable. J'aurais pu tout faire dans le même facilement, mais pour l'instant je préfère séparer pour ne pas tout craquer en cas de crash du QA. Après, je n'ai pas une super grosse installation de fou avec 95 modules non plus, mais il parait que ce n'est pas la taille qui compte

Moi aussi

Meteoconcept j’ai tout fait pour me forcer à l’utiliser comme source dans mon QA car cocorico, mais finalement non. Et rien trouvé pour toi concernant la lune…

Non c’est openweather

Dans weatherbit je trouve : "moon_phase": 0.99 "moon_phase_lunation": 0.48 "moonrise_ts": 1530341260 "moonset_ts": 1530351260

Dans openweather je trouve dans le json forecast 7 jours : "moonrise": 1618284960 "moonset": 1618339740 "moon_phase": 0.04

Suite à la création d’un QA, j’ai des accès pour meteoconcept, weatherbit, et openweather . Je peux regarder ce qu’il y a de dispo dans les api si tu veux.

La patience ?

Thank you so much @jang for your altruism and this big time you took to share and explain to us I read everything during my lunch time, but I need to read again several time in a calm position for better understanding Let's see this week-end with a long coffee. Thanks again for this nice training

Bonjour, et bienvenu sur ce très bon forum Bonne ambiance, grosse expertise pour certains, et partage du savoir pour la plupart  Au plaisir de te lire 

But this way, is changing the philosophy of my code for coding conditions... Until now I used a lot of local variables updated by conditions, and used later in actions... Good news is that it should decrease the number of local variables. Bad news is that it should increase the number of local conditions.

Très intéressant comme news ça Merci Ca donne envie d'aller fouiner/surveiller un peu sur le net, même si les miennes n'ont que 1 an, je suis curieux de voir les évolutions à venir, d'autant que bizarrement il n'y en a pas des tonnes de têtes Zwave

Crystal clear, thank you @jang I understand the pro/cons, so as I already moved my actions (and reduced them thanks to parameters in functions), I will think and work to move also conditions, and play will rules About event and refresh, I still need to read again several times what @Lazer has done, and also what you are proposing to me for reading I like it, but step by step

@jang @Lazer and all others members of course , continuing to talk around a coffee for more knowledge and improvement, I understand the architecture, but why do you prefer this way to code: local function condition1(self) return true end local function condition2(self) return math.random(1,3) > 1 end local function condition3(self) return false end local function action1(self) fibaro.call(...) end local function action2(self) fibaro.call(...) end local function action3(self) fibaro.call(...) end local rules = { {condition=condition1,action=action1}, {condition=condition2,action=action2}, {condition=condition3,action=action3} } function mainCode(self) for _,r in ipairs(rules) do -- Test conditions and run actions if true if r.condition(self) then r.action(self) end end end compare to this structure of code: local function action1(self) fibaro.call(...) end local function action2(self) fibaro.call(...) end local function action3(self) fibaro.call(...) end function mainCode(self) -------------------------------------------------- if condition1 then action1(self) end -------------------------------------------------- if condition2 then action2(self) end -------------------------------------------------- if condition3 then action3(self) end -------------------------------------------------- end Maintenance? Performance? Something else I didn't catch? Or pure personal point of view? Calling a function is it longer than executing directly the content in the code?

Page précédente :

Ben pas sûr que ce soit Fibaro. Nous avons décidé de faire mieux que de simples scènes bloc en codant nous-mêmes… ben du coup la moindre variante sémantique compte et doit être comprise. Et comme souvent tout dépend de nous-mêmes du coup

Bon deux fois que je lis ce post. Pas évident… J’y retourne car ça m’intéresse de comprendre et l’appliquer à mes QA Surtout l’exemple 3

Tant mieux si cela fait ce que tu voulais alors Après je n'ai absolument aucun mérite. Comme j'aime à le répéter afin de rendre à César ce qui lui appartient, la majorité de ce que je sais, je l'ai appris à gauche et à droite sur notre forum Tu sauras le partager à ton tour lorsque quelqu'un posera à nouveau la même question que toi

Comme il n'y a pas que des sujets sérieux et techniques, après tout c'est aussi un forum de détente , un tout petit sujet pour souligner que notre @Yohan est dans la place ce soir. En tout cas connecté parmi nous apparemment Salut Yohan, alors, on prépare les fêtes de Noël ?

Ça a l’air d’être dans le même esprit, au détail près de la description de la structure de la table dans le code.

Bonjour, et bienvenu sur ce très bon forum Bonne ambiance, grosse expertise pour certains, et partage du savoir pour la plupart  Au plaisir de te lire 

Allé un truc comme ça par exemple, histoire de te laisser comprendre la structure du code pour trouver ton paramètre puis le modifier (attention je n'ai pas réellement essayé de mon coté) : function QuickApp:modif() local toto = api.get("/devices/"..Walli) toto.properties.parameters[36].value = 99 --ou 33 api.put("/devices/"..Walli, toto) end

Sinon tu fais une simple boucle de surveillance avec setTimeout toutes les secondes par exemple, mais ce n’est vraiment pas très classe quand même…

onInit() est la première fonction exécutée au début de ton QA. Elle ne surveille pas ton QA et les événements. Si tu veux une surveillance il faut te tourner vers :

Si j'avais écrit comme ci-dessous je l'aurais vu. Comme quoi la structure et la forme du code compte pour t'y retrouver ---fermeture function QuickApp:close() -- bouton pour fermer ton volet fibaro.call(279, "close") -- fermeture de ton volet setTimeout(function() if fibaro.getValue(279, "power") >= 80 then self:stop() end end, 5*1000) -- attendre 5s avant de vérifier ta consommation puis exécuter une action end ---STOP function QuickApp:stop() -- bouton pour arrêter ton volet fibaro.call(279, "stop") self:debug("STOP") end ---ouverture function QuickApp:open() -- bouton pour ouvrir ton volet fibaro.call(279, "open") self:debug("Ouverture") end