Steven

Perso, j'ai un fake device de type actionneur. Au passage sur On j'envoie une requête http à ma ZiBASE et inversement... Par contre, attention, je ne gère pas le retour d'état car la cela deviendrait super complexe. Donc dans mon cas, cela fonctionne parfaitement car je le pilote exclusivement par le biais de la HC2. Envoyé de mon SM-G935F en utilisant Tapatalk

La V4 n'est pas capable de faire un push lors d'un changement d'état ? Ainsi au lieu d'aller chercher le R1 toutes les X secondes, c'est le changement d'état du R1 qui avertirait la HC2. C'est plus optimal. En gros, tu crée un VD avec 2 bouton (On/Off) chaque bouton envoi le code On et Off à l'IPX. <== Ca c'est déjà fait normalement ? Avec des icones différentes sur le bouton si tu veux. Depuis l'IPX tu utilise l'URL suivante : http://<login>:<password>@hc2_ip/api/callAction?deviceID=<ID_VD>&name=pressButton&arg1=<ID_BOUTON>

J'ai une meilleure solution : @MAM78 HELP ... @MAM78 HELP ... @MAM78 HELP

Si tu en as besoin, car l'IPX ne se contrôle pas seulement depuis la HC2 donc l'état peux changer et il est donc nécessaire d'avoir son état sur la HC2. Malheureusement, je n'ai qu'un pauvre IPX V3 (reçu gracieusement (merci Pascal) en échange d'un plugin que je n'ai jamais pu faire, vu qu'il n'existe toujours pas) je ne peux donc pas aider.

Me semble qu'il manque des lignes sur le premier scénario "par variable globale".

Ben t'as l'option "Inspecter l'élément" :-)

Aucune garantie de fonctionnement : Affiche la liste des icônes disponibles Appuie sur [F12] Une nouvelle petite fenêtre s'ouvre, sélectionne l'icone de gauche (flèche 1) Puis tu clique sur l'icône que tu veux (flèche 2) Tu note le numéro de l'icône (flèche 3) ici c'est le "1017".

Cela signifie que dans ton tableau doors = {...} il y a quelque chose qui n'est pas un numéro. Vérifier que tu n'aies pas de numéro entre guillemet, ni de virgule en trop.

Ok, j'ai trouvé, il y a un soucis dans le code qui bloque les appels nécessitant un true, false au lieu de 1,0 La ligne local valeur = v.value or 0 Il faut enlever le "or 0" Car si la valeur envoyé est "false", il va le transformer en 0 au lieu de "false". Une fois que cette correction est appliquée, tu pourras envoyé : http://192.168.0.195/api/callAction?deviceID=180&name=setProperty&arg1=ui.Json.value&arg2="{'id':160,'value':true}" ou http://192.168.0.195/api/callAction?deviceID=180&name=setProperty&arg1=ui.Json.value&arg2="{'id':160,'value':false}" Et voilà, maintenant tu as un script capable de géré (je l'espère) tous les fakes devices.

Qu'est ce qu'on fait ... on attends la v.2.0 ? Je pense qu'on est plus ou moins unanime. Pour une fois que l'API ne prenait que quelques heures tranquille à mettre en place, il fallait qu'ils gâchent tout avec un prix et design mal adapté.

J'ai pas vu l'article Je vais jeter un oeil mais uniquement pour information. Merci pour le tuyau.

Voilà 1. Importer le VD External.vfib (c'est juste un VD avec un seul label) ... noter son ID 2. Créer une scène et copier le code du fichier External.lua 3. Modifier 194 ui.Json.value par le numéro de ton VD (importé en point 1) A partir de maintenant, tu peux envoyer des requêtes HTTP de type GET : Pour un ID <-> Valeur http://<ip hc2>/api/callAction?deviceID=194&name=setProperty&arg1=ui.Json.value&arg2="{'id':181,'value':55}" Pour plusieurs ID <-> Valeur http://<ip hc2>/api/callAction?deviceID=194&name=setProperty&arg1=ui.Json.value&arg2="[{'id':181,'value':55},{'id':182,'value':28.2}]" External.vfib External.lua

A nouveau, facile a dire. Le soucis est que la Zibase ne permet que de faire des appels HTTP de type GET et la HC2 permet de modifier des données uniquement par le type PUT. Il y a une astuce que je vais de donner au prochain post, le temps de la mettre en place. Il est possible de modifier un label d'un VD via une requête HTTP GET ... la Zibase pourra donc modifier ce label. Ensuite, on crée un scénario qui agit dès que le label du VD change, et qui va lire la donnée reçu et modifier la valeur. Ainsi tu pourras modifier n'importe quel valeur de n'importe quel Fake Device sans ajouté d'autre scénario. De plus tu pourras caché le VD et le scénario. Je te tiens au courant.

Quelqu'un a déjà testé LaMetric Time ? J'ai jeté un oeil aux API, c'est super simple et vraiment complet, on peux tout gérer (luminosité, information, ...). Mais bon, 185 € ... je passe mon tour.

Ça c'est facile, tu reprends le même scénario que pour le capteur d'humidité mais tu mets 0 ou 1 comme valeur. 0 étant fermé. Enfin facile est une manière de parler .. c'est jamais facile.

Je sais ... moi aussi je tremble depuis 1 semaine. Je n'arrive plus dormir, je suis angoissé, j'ai parfois des crises de panique ... mais je vais survivre. On va tous survivre Trêve de plaisanterie ... il s'en sort très bien

A ce que je comprends, @Guru semble dire que même en ayant resetter le FGK, ce dernier reste reconnu pas la HC2 ... impossible donc de le réinclure sans le supprimer. Pourtant la procédure dit bien que TOUTES les données seront perdues : config, contrôleur principale et données z-wave. Perso, je n'ai jamais testé ... quelqu'un ?

@jojo a toujours un cran de retard depuis qu'il est passé sur LifeDomus (LD), ça lag un peu, faut l'excuser. Edit : je suis aussi avec intérêt mais surtout la partie simulation et détection incendie/inondation comme @BenjyNet (mon alarme ne sera jamais reliée à ma box).

Il y a cette procédure pour resetter le FGK et pouvoir ensuite le réutiliser comme nouveau module.

Je ne peux pas développer l'idée de la bufferisation car je n'y ai jamais pensé et je n'en n'ai pas besoin. A vu d'oeil, sur la HC2, il n'y a que le coupe JSON/variable globales de disponible et c'est pas top. Heuuuu, prendre une HC2 pour pouvoir avoir accès au code me semble un choix étrange vu que cela reste une box fermée comme toutes les autres. Jeedom me semble plus ouvert et ton Synology encore plus. Moi j'ai l'excuse que Jeedom n'existait pas et que je suis un flemmard qui veux un truc qui fonctionne sans avoir besoin de mettre les mains dedans. La différence entre une box domotique et un PC est justement que la box est "fermée", "bridée" pour que l'utilisateur ne puisse faire que ce qu'on lui propose. Cela non pas de le but de l'embêter mais d'éviter les erreurs de manipulations. Apparemment, j'ai mer*dé vu que tu as l'impression que j'ai discrédité quelque chose. Ce que j'ai juste voulu dire est que si on atteint une limite c'est souvent que le moyen pour y arrivé qui n'est pas le bon. Je pourrais te citer quelques utilisateurs qui ont aussi ce mérite mais je suis 100% d'accord avec toi et c'est grâce à des gens comme toi que ce forum est l'un des plus utile et actif sur le sujet (voir le plus utile ET le plus actif). Ça, je crois que je suis au courant ... j'ai assez perdu de temps à savoir à quoi elle servait cette fonction et je trouve que d'en discuter est très utile. Tu as juste mis en post en disant "attention aux limitations" alors je me suis permis de réponde (apparemment maladroitement). Donc, excuse moi encore d'avoir donné mon avis sur les soucis de limitation de cette fonction en ayant utilisé les mauvais mots ("soucis de conception"). Mais je ne te promets pas de ne plus le faire car je suis naturellement maladroit

Information super utile bravo Steven Je sais qu'il y a un gars qui a fait un scénario très complet sur la simulation de présence. Par contre, je ne me souviens plus de qui, ni où (je sais juste que c'est pas sur ce forum) ... donc si quelqu'un s'en souvient ? Car moi et mon grand âge, on y arrive plus.

Si tu as trop de requêtes qui partent en même temps, c'est pour moi un soucis de conception. Il suffit de bufferiser les infos et de les envoyer de temps en temps. Surchargé un réseau n'est jamais la solution. Pour la gestion des traces, personnellement, je ne connais aucun système qui n'utilise pas la bufferisation .. .même Windows le fait . Et je ne vois pas pourquoi on enverrais un plus d'un email/push/tts, ... par secondes ... c'est du spam mais ce n'est pas le débat. Perso, je pense que 10 appels simultanés .. c'est déjà énorme ... ou alors c'est que le traitement effectué par le scénario est trop long et n'est pas capable de ce terminer suffisamment tôt pour libérer les instances. Ce que tu essaie de mettre en place avec les logs ... n'est pas du domaine de la domotique mais de l'informatique. Ce besoin de connaître les logs n'intéresse réellement que les informaticiens et non pas les utilisateurs. Donc oui, tu as raison, il y a des limitations mais ces limitations sont là pour protéger un utilisateur qui aurait un mauvais code (boucle sans fin, trigger avec ID inutile, ...) .. ces limitations ont été volontairement ajoutés il y a pas si longtemps que cela. Et sérieusement, c'est un très bon garde fou pour éviter les soucis. Bref, ce que je veux dire par la est : "Tu mets en garde les utilisateurs que le système à ses limites et qu'il doivent faire attention à cela" et moi je dis "Si vous arriver aux limites c'est que vous devez sûrement revoir quelque chose". On parle donc de la même chose mais différemment. En aucun cas je ne remets en question ce que tu as réalisé (logs, ...) c'est juste un autre regarde sur ces fameuses limitations dont tu parles. P.S: Le sleep n'est plus le moyen a utiliser, il y a le setTimeout() qui ne consomme rien. P.S2 : Cela doit être la première fois que j'écris un message qui dit que Fibaro a fait un truc de bien blame on me.

Maintenant, si on reste réaliste, on parle de domotique ... je vois mal quelqu'un s'amuser à allumer/éteindre une lampe plus de 2 fois par secondes En ce qui concerne le nombre d'appel en parallèle, même combat, si on doit appeler une scène plus de 10x en simultané, je pense qu'il y a un soucis de conception et non pas de limitation.

Tu as le / 10 qui dérange pour réellement pouvoir simplifier. Si tu n'as pas plus de Fake Device, cela ne vaut pas la peine de se prendre la tête, ton script est très bien. Si tu commence à en avoir une dizaine, il faudra le repenser gentiment pour éviter de mettre à jour 10 modules en même temps pour rien. En tout cas bien joué

Alors, une première scène pour tout éteindre (noter son ID pour plus tard) : local interrupteurs = {8, 10, 12, 14, 21, 24, 26, 35, 60, 80, 167} for i = 1, #interrupteurs do fibaro:call(interrupteurs[i], "turnOff") end Et la scène qui contrôle et demande local interrupteurs = {8, 10, 12, 14, 21, 24, 26, 35, 60, 80, 167} local id_de_la_scene_qui_eteint = XXXXXX local message = "" for i = 1, #interrupteurs do local interrupteurname = fibaro:getName(interrupteurs[i]); if (tonumber(fibaro:getValue(interrupteurs[i], "value")) > 0) then interrupteurname = string.gsub(interrupteurname," ","_") if (message ~= "") then message = message .. ", " end message = message .. interrupteurname end end if (message ~= "") then if (message:find(","))then message = message .. " sont allumés, voulez-vous les éteindre ?" else message = message .. " est allumé, voulez-vous l'éteindre ?" end api.post('/mobile/push', { ["mobileDevices"]={176}, ["message"]=message, ["title"]='Question:', ["category"]='YES_NO', ["data"]={["sceneId"]=id_de_la_scene_qui_eteint} } ) end A tester .. (ce que je n'ai pas pu faire ) Courage