jjacques68

Alors en fait si, sur les binarySwitch ça marche. Le soucis c'est que j'ai aussi des MultiLevelSwitch, Dimmer 2, ... et tous n'ont pas la fonction auto off. Certain l'ont, mais ça ne fonctionne que si tu passes par l'action des Input du module. ça me fait bien chi... cette affaire, je pourrais me passer de beaucoup de lignes de code... Question réactivité, je passe par l'interrogation constante de l'API refreshStates, qui me permet de détecter le passage à True/False des PIR et donc de déclencher les lumières. C'est réactif, j'ai pas à me plaindre. Mais c'est compliqué.

ben pour les lumières, j'ai a abandonné cette histoire auto off... le off est géré par scène quand le PIR repasse à false. et c'est la tempo du PIR qui fixe la durée d'allumage... bien dommage...

Et si mets > 0.0 ? Envoyé de mon iPhone en utilisant Tapatalk Pro

etrange... tu as essayé en enlevant les autres conditions, juste garder celle du motion et de la luminosité ? { operator = "all", conditions = { {type = "device", id = 54, property = "value", operator = "==", value = true, isTrigger = true}, {type = "device", id = 149, property = "value", operator = "<", value = 3, isTrigger = false} } } si tu as affiche dans le debug la valeur de luminosité lorsque la scène est triggée, ça donne combien ?

pas de nouvelles, bonne nouvelles ?

Bon j'ai essayé, j'avais les backup sous le coude au cas où Ben rien à faire, même en forçant la version de l'API (dans le .fqa), j'ai rien. Pas une seule ligne de code n’apparaît. Je vois les variables du QA, tous les label sont superposé les uns sur les autres. Mais c'est tout.

avec la nouvelle version de firmware oui ! dans ce sens ça marche ! Mais dans l'autre sens... ???

ça nan, j'ose pas prendre ce risque ...

ben c 'est pourtant le cas, si tu édites le fichier .fqa, tu verras dans la première ligne, la version de l'API. Ton QA est en 1.2 chez moi, si j'exporte un QA, je suis en 1.1... Après, la dernière mise à jour a fait beaucoup de changements, je comprends que l'import/export vers une version plus ancienne pose problème... faudrait peut-être le préciser dans ton premier post, "à partir de la version xxx". Je voulais voir la méthode que tu utilises pour interroger l'Ecodevice... J'ai pu le voir en éditant le fichier .fqa... Moi je passe par une socket TCP, pas par une requête HTTP. Le résultat est le même, heureusement ...

et ben si justement ! j'ai essayé de l'installer. J'ai rien, aucun champs, pas une seule ligne de code ! et cela vient du fait qu'avec la dernière version, il y a la gestion des "fichiers" dans les QA. Moi je suis resté en version n-1. Donc visiblement les QA réalisés dans la dernière version ne sont pas utilisables sur la version n-x !

tu as réalisé ce QA avec quelle version de Firmware de la HC3 ?

il ne me semble pas que le fgbs soit un compteur d'impulsion. j'en ai 2 (plutôt des smart implant) j'ai regardé la doc et les paramètres (rapidement), j'ai rien vu qui le permettait... Il te faudra gérer le compteur par script... ce sera un peu lourd... au cas où, regardes dans ma signature, y a topic complet sur la gestion de l'eau via un IPX, ça peut inspirer...

entièrement d'accord ! Mais on retombe sur le problème de @mattrix, à savoir, seul, si t'as pas plus de compétences que ça en élec, c'est pas possible... Pour plein de raisons (sécurité, qualité, rentabilité, ...) Pas exclusivement non, comme dit, 1 en faisait un tout petit peu, et encore c'est souvent des marchés publiques (église de Cernay, Collège de Burnhaupt, le tout en KNX)

I tried and in deed : it's very strange... It transforms the values... I understand more why I had some problems with the boolean too... they are transformed in 0/1... I understand the "marshalling" too... You reported this in February !!! - there was however some update since... I hope they will make something... thanks for explains !!

je me permets d'ajouter, que quelques foyer s'équipe avec les box comme somfy, où tout est ultra simplfié. Je me pose souvent la question quand je code mes script: si un jour j'avais ma boîte, est ce que je proposerais ce genre de script ? la réponse est clairement non ! j'ai beau faire attention au maximum, y a toujours une merde qui te tombe dessus un jour que tu t'y attends pas. On peut pas toujours imaginer tous les cas, surtout quand le facteur humain s'en mêle ! Proposer ce genre de système chez un client peut être très dangereux ! Donc en installant un système domotique chez qqun en simplifiant au maximum pour ne pas prendre de risque, les clients se rendrait vite compte à un moment donné qu'une solution grand publique (somfy, legrand, ...) coûte moins chère et pourrait être fait par eux-mêmes... Sans parlé, comme je disais avant, des objets connecté tout pourri qui plaisent énormément car pas chère du tout ! je me trompe ?

il y a 2 ans de ça maintenant, je me disais aussi pourquoi pas essayer... Mais pas à mon compte, justement à cause des soucis "électrique"... Je me suis dit donc que j'allais faire le tour des boites d'électricité qui étaient suspectible de faire des installation domotique. Chose faite, mais alors... ... j'en ai fait 6. j'ai toujours été très bien accueilli. Mais sur les 6, sans vous mentir, 3 m'ont demandé ce que c'était la domotique... Après leur avoir expliqué, ils m'ont fait comprendre que c'était pas pour eux, trop compliqué, trop... trop tout quoi. les 3 autres, ils faisaient très rarement du KNX. je m'y connaissais un peu car j'ai énormément suivi le KNX à l'époque, j'avais le logiciel ETS (lite) pour jouer dans mon coin. dans les 3 boîte, ils avaient déjà un gars qui bidouillait un peu. Je dis bien bidouillé, car une des entreprise à fait un chantier assez imposant en 100% KNX chez ma sœur, et bien je peux vous dire qu'aujourd'hui, y a encore des trucs qui marchent pas... et moins performant que chez moi avec la HC3 bref... Mais la demande de domotique est si faible (peutêtre un chantier par an) qu'il n'était pas possible d'embaucher qqun pour faire que ça. Une boîte m'avais proposé un poste mais la domotique aurait occupée peut-être 1 % du temps. Le reste aurait de tirer des cables... La conclusion, est que la domotique (la vrai, je parle pas des objets "connectés" à la con dans tous les coins de la maison) n'est absolument pas, mais absolument pas dans l'esprit des personnes. C'est un art de vivre, un état d'esprit, qui n'intéresse qu'une partie infiniment minuscule, voir totalement négligeable, de la population française... La preuve, rien que le mot "domotique" reste inconnu auprès de la majeur partie de la population (même Word ne le connaît pas ) Et je pense pas que ça changera pas de si tôt... J'ai envie de dire que l'on a 15 ans d'avances avec nos petites box... du moins en France... C'est bien dommage...

En effet, il y a un gros soucis sur le formatage des tables JSON !!!! exemple simple à reproduire : dans un QA, faire cette fonction : vous aurez compris que celle-ci va nous afficher le type de la variable transmise... function QuickApp:Display_Type(value) print(type(value)) end On peut la tester depuis ce même QA ou un autre avec : self:Display_Type( {1, 2, 3} ) le résultat sera donc forcément un type "table" ! mais depuis une scène maintenant : en appelant la fonction comme ceci : fibaro.call(id_QA, "Display_Type", {1, 2, 3}) le résultat affichée est de type "string" !!!!!!! il faut faire : fibaro.call(id_QA, "Display_Type", json.encode({1, 2, 3})) pour avoir le type "table" !!! J'ai encore loupé un épisode ????

je vais pas être d'une grande aide, j'ai eu le même genre de soucis, Ai voulu faire un retour à 0 des relais au,bout d'un certain temps, mais ça a jamais marché comme je le voulais. Après j'ai jamais attendu 1h ou 2... Mais il me semble que l'auto off ne fonctionne que si on utilisé les nitrée IN1 / 2 du module non ? si on passe le relais sur On par un autre chemin, il ne revient pas à 0 ! j'ai cru comprendre ça un jour...

pour les drivers USB to COM, faut prendre les drivers de chez "Prolific" ? y a une vieille histoire si je me souviens, selon le chipset... Et il me semble que les les drivers de prolific passe avec tous les modèles...

YEESSSS ! it works fine ! Now I juste have "quickAppChild" in interfaces. but there is a bug with the IHM : "light" is still display... while in the API it's ok : all these functions/possibilities are not explain in the manual of Fibaro... Once again, thank you !!!!

Ok with "quickAppchild" as default. I understand this type. But the type "lights" is added too. I would like to delete the others types. Just to keep "quickAppchild".

@Lazer

yes super !! OK for the properties, but not for Interfaces : self:createChildDevice({ name = "toto", type = "com.fibaro.binarySwitch", initialProperties = { deviceIcon = 1011, isLight = false, categories = {"other"}, }, initialInterfaces = {"quickAppChild"}, }, MyClass) It still set interfaces with "lights" and "quickAppChild"... I try with : initialInterfaces = {} but same result...

hello ! Autre question concernant l'initialisation à la création des QA child : en effet on leur donne leur type avec : local child = self:createChildDevice({ name = "toto", type = "com.fibaro.binarySwitch", }, _MyClass) Mas par défaut il les déclare en "Light" (avec tout ce qui va avec : propriété isLight = true ; interfaces = ["lights", "quickAppChild"] ; categories = ["light"]) et si on veut mettre autre chose !! sans avoir à se taper tous les child à la main !! attention au jeux de mots : "Rôle" = "interface"... J'ai trouvé comment faire pour l'icone et la catégorie : dans le code d'init du child : function MyClass:__init(device) QuickAppChild.__init(self, device) self:trace(string.format("[%s] %s - init" , self.id, self.name)) self:updateProperty("deviceIcon", 1011) self:updateProperty("isLight", false) self:updateProperty("categories", {"other"}) end y a juste besoin de le faire la première fois. On peut laisser le code, mais il ne sera plus utile. remarque : J'ai pensé du coup à le glisser dans la fonction de création du child, mais il le prend pas en compte : local child = self:createChildDevice({ name = "toto", type = "com.fibaro.binarySwitch", deviceIcon = 1011, isLight = false, categories = {"other"}, }, _MyClass) fin remarque. mais pour le rôle (donc interface), pas moyen d'y arriver, j'ai du me les faire à la main ! le problème est que le rôle ne fait pas partie de la section "propriété" dans l'API. donc j'ai essayé la bonne vieille méthode du api get/put, sans succès : local MyApi = api.get("/devices/"..self.id) MyApi.interfaces = {"quickAppChild"} res = api.put("/devices/"..self.id, MyApi) pas de message d'erreur, mais pas de modifications dans l'API... qqun a une idée ?? ou je fais complètement fausse route !?

l'humidité ? pourquoi ? sec ou humide ils attaquent quand même !!