Lazer

Si tu as la documentation de ton module, les paramètres doivent être indiqués dedans. Tu peux alors les renseigner manuellement dans la box.

Merci mais je n'arrive pas à télécharger le fichier... toi aussi ?

@Nico Afin de préparer la compatibilité de mon QA IPX800 v4 avec l'EcoDevice RT2, est-ce que tu pourrais me donner le résultat des URL suivantes qui sont inédites à ce produit : http://EcoDevices_RT/api/xdevices.json?Index=all http://EcoDevices_RT/api/xdevices.json?key=apikey&DIndex=P http://EcoDevices_RT/api/xdevices.json?key=apikey&DIndex=S http://EcoDevices_RT/api/xdevices.json?Price=all http://EcoDevices_RT/api/xdevices.json?key=apikey&DPrice=P http://EcoDevices_RT/api/xdevices.json?DPrice=S http://EcoDevices_RT/api/xdevices.json?key=apikey&Get=TI http://EcoDevices_RT/api/xdevices.json?Get=P Vu la quantité de résultat que tu risques d'obtenir, il vaut peut-être mieux le mette en fichier attaché plutôt que de copier/coller le texte sur le forum. Merci

Ah oui OK Mais ça ne seront pas des QA enfants, puisque un QA enfant n'a pas de code LUA, les enfants dépendent à 100% du code LUA du parent. Donc c'est un QA totalement indépendant, ce qui signifie que l'utilisateur doit maintenant la correspondance d'ID entre le vrai QA et celui qui contient la config... pas super non plus

Hum, les "Autres solutions domotique" on peut les sortir de "Bienvenue" ? D'ailleurs on pourrait y ajouter une sous-section Home Assistant

Remonte petit topic Je l'ai déplacé dans la nouvelle sous-section dédiée à la marque Pour info j'ai posé le miens il y a quelques mois. Je l'avais acheté il y a longtemps, peu de temps après sa sortie. Il avait donc un vieux firmware. Et j'avais le souci du bug de sensibilité des touches tactiles : soit il fallait appuyer trop longtemps et trop fort, soit les touches étaient trop sensibles et faisaient défiler les fonctions toutes seules ! Impossible de trouver le bon réglage. Il faut faire procéder à la mise à jour gratuite du firmware par GCE Electronics, il faut les contacter sur leur Helpdesk puis ouvrir un port sur son routeur pour leur donner accès à distance. Depuis il fonctionne très bien

Welcome to the forum

Lien vers le Wiki officiel de l'IPX800 v4 : http://gce.ovh/wiki/index.php?title=IPX800_V4 Et plus généralement, toutes les extensions : http://gce.ovh/wiki/index.php?title=Accueil

Tant que ce n'est pas un doigt ... Comment il va d'ailleurs le tient ?

Oui, mais vu le nombre d'options considérables d'options à gérer (chaque entrée, sortie, compteur, numérique, analogique, teleinfo, etc) sur les IPX800/EDRT2, ça va faire soit une variable énorme avec plein d'options dedans (et l'utilisateur sera responsable de faire correctement l'encodage JSON), soit un très grand nombre de variables (1 option par variable) Je ne vois rien d'idéal pour l'instant

C'est beau ça C'est @Nico qui va pleurer Du coup j'ai vu qu'ils ont bien pris en compte la demande de réintroduire l'UDP, mais je pense qu'il va falloir être patient, il n'a pas donné de date....

Je ne suis pas certain que le VD soit encore d'actualité, il date des tous débuts de la HC2.... l'API a pas mal évoluée depuis. Le JSON d'un module tu peux le récupérer via l'API grâce à l'URL suivante sur l'adresse IP de ta box (remplacer 150 par l'ID de ton module) : /api/devices/150 Tu récupères quelque chose qui ressemble à ça, avec la propriété "dead" qui nous intéresse (en bas de ma capture) : { "id": 150, "name": "Eco-Devices", "roomID": 219, "view": [ { "type": "json" } ], "type": "com.fibaro.powerSensor", "baseType": "com.fibaro.multilevelSensor", "enabled": true, "visible": true, "isPlugin": true, "parentId": 0, "viewXml": true, "configXml": false, "interfaces": [ "energy", "power", "quickApp" ], "properties": { "apiVersion": "1.1", "categories": [ "other" ], "dead": false, "deadReason": "", En LUA, tu peux aller récupérer tout le JSON grâce à api.get("/devices/150") ou directement la valeur qui t'intéresse via fibaro:getValue(150, "dead") Pour forcer un polling, comme dit c'est un peu plus technique, il faut utiliser les outils de dév de ton navigateur web pour récupérer l'appel qui est fait à l'API (ce n'est pas officiellement documenté) Par exemple je l'ai déjà fait dans une scène sur la HC2 ça ressemble à ça (il faut au préalable connaitre l'ID du module parent du module que tu veux interroger) : local postURL = 'http://127.0.0.1:11111/api/devices/' .. parentId .. '/action/poll' local httpClient = net.HTTPClient() httpClient:request(postURL, { success = function(response) if response.status == 200 or response.status == 202 then fibaro:debug("Poll device OK") else fibaro:debug('<span style="color:red;">Error : status='..tostring(response.status)..'</span>') end end, error = function(err) fibaro:debug('<span style="color:red;">Error : '..err..'</span>') end, options = { method = 'POST' } })

Ce qui m'embête, et c'est la raison pour laquelle je n'ai pas encore partagé mon QA pour IPX800 v4, c'est que l'interface Web de la HC3 ne permet pas de modifier les variables des modules enfants. Du coup je ne sais pas partager un QA aussi complet qui soit facile d'installation.... j'aurai aimé éviter de laisser l'utilisateur modifier le code LUA comme on a toujours été obligé de le faire sur les VD, ça complexifie tellement l'installation pour les néophyte. Et cela complexifie aussi l'évolution du code, car à chaque mise à jour du code, il faut que l'utilisateur modifier l'entête LUA avant le copier/coller. Je viens de jeter un oeil plus approfondi à l'API de l'ED RT2, elle est identique, mais plus complète que celle de l'IPX800. Notamment sur les remontées des étiquettes de la téléinfo, et des pinces. Ca fait un nombre de possibilités infinies, et je crois que je vais devoir me résigner à laisser l'utilisateur modifier le code LUA Si quelqu'un a une idée....

Oui justement ça c'est l’icône d'un nœud mort = dead

Une sous section informatique a été demandé il y a très longtemps déjà, à plusieurs reprises même, et ça a toujours été refusé. Moi aussi je préfèrerais, car il y a pas mal de discussions informatique/réseau/geekerie en tout genre qui y trouveraient leur place. Après pas obligé de découper en sous section nas/virtu/réseau etc, ce n'est pas un forum d'informatique non plus, il y en a déjà plein qui le font mieux @Moicphil si tu nous entends...

Bienvenue sur le forum

Et son topic unique : https://www.domotique-fibaro.fr/topic/4993-nodon-prise-intelligente-z-wave/

J'allais dire absolument, mais en fait après avoir regardé le 1er post, je préfère le laisser là où il est... car c'est un tutoriel, il n'y a pas de présentation du produit. Je ne sais pas si un autre topic déjà existant en traite, je ne m'étais pas trop intéressé au RT2 jusque là. Si je me motive, je ferai une petite page de présentation rapide. EDIT j'avais déjà fait tout le boulot à l'époque Google est magique ! Voilà qui est déplacé au bon endroit :

@Bloug désolé toujours pas compris OK tu trolles, c'est marrant 5 minutes, mais si tu persistes, fais une proposition constructive, au moins ça servira à quelque chose. En fait tu veux les, pardon LE mettre où le seul et unique module Nice en Z-Wave ? (enfin à ma connaissance... mais je ne connais pas la catalogue par cœur) Si on se retrouve avec 2 catégories NICE, une dans Z-Wave avec 1 seul module, et une autre là où elle est dans 'périphériques et matériels autres', ça correspond certes plus à la réalité, mais ça disperse l'information. D'autant plus qu'on n'a jamais trop parlé des autres modules Nice jusqu'à présent. Donc 2 rubriques Nice à moitié vide... je trouve cela bof bof Bref, le forum évolue en fonction des sorties de nouveaux modules chez les constructeurs, mais tu l'avais bien compris n'est ce pas ? Nodon a une catégorie dans Z-Wave parce que c'est ce dont on traite principalement sur le forum. Si la HC3 devient multi-protocole (enfin uniquement Zigbee, on peut oublier EnOcean), certainement que plus de gens parleront des modules Zigbee sur le forum et qu'il faudra créer une catégorie à ce moment là. Comme dit, le forum évolue. @mprinfo Homekit je les avais oublié ceux-là ! Mais on n'en a jamais trop parlé sur le forum, il doit y avoir 2 ou 3 discussions maximum. Cela n'a jamais passionné les foules on dirait. On peut faire une catégorie pour ça rien que pour toi vu que tu adores Apple Tiens d'ailleurs moi je suis pour la fusion des sections Aeon Labs et Aeotec, je suis surpris que personne n'est fait la remarque plus tôt. C'est la même marque (ou plutôt c'est la marque d'un constructeur....)

je t'avoue que je ne te suis plus là ??? désolé mais pas compris (ça doit être mon coté fanboy... man fanboy de qui ?)

Ou alors c'est Domadoo l'importateur en France. Oh wait....

En effet, faudrait le mette dans autre modules Z-Wave à ce moment là, mais vu qu'ils ne font pas trop de Z-Wave à la base, mais plutôt leur protocole propriétaire. Bref, y'a aucun endroit parfait, Nice c'est batard on verra comment les choses évoluent en fonction des prochains modules qu'ils sortent.

Oui je vous disais par ailleurs, ne vous précipitez pas à réinventer la roue, je pense que mon QA IPX800 pourra gérer sans souci l'Eco Devices RT2, l'API semble totalement identique. Il faudra juste que j'intègre la remonté de la teleinfo et des 2/3 spécificités de l'Eco Devices. Un seul code LUA à maintenir c'est quand même plus simple pour tout le monde.

C'est loin d'être simple.... Le getValue() n'interroge pas le module, mais uniquement son dernier état connu dans la base de données de la HC3. Dans les grandes lignes, voici les 4 pistes que je te propose : oublier ton idée, le Z-Wave n'est pas fait pour ça... on ne doit pas "pinguer" un module en continu comme on le ferai sur un réseau IP, au risque de saturer le réseau Z-Wave si vraiment tu t'obstines : faire un "polling" du module, tu peux le forcer via l'API de la box (pour obtenir la méthode, tu fais F12 pour obtenir les outils de dev de ton navigateur, et tu regardes l'URL et les données envoyées au moment où tu cliques sur ce bouton dans la box) attendre quelques secondes au bout d'un certain temps, voire même d'un temps certain, si la box n'arrive pas à communiquer avec le module parce qu'il est débranché, elle le marque en dead (dans ses propriétés accessibles dans son JSON via l'API) lire cette valeur dead et faire ton scénario si le module est débranché se souvenir que mon premier conseil d'oublier ton idée était... une bonne suggestion si finalement tu persistes dans ton obstination, surtout ne tente pas de communiquer avec le module trop souvent.... idéalement il faut que ce polling soit au moins aussi lent que le polling global enregistré dans la box (et plus y'a de modules sur le réseau, plus le polling est allongé, voir supprimée (et hop, retour au point n°1 !!! ))

Mais c'est bon, le "heos" est juste un champ du JSON. Si tu demandes à Notepad++ de te formater le JSON, ça devient très clair : { "heos": { "command": "system/prettify_json_response", "result": "success", "message": "enable=on" } } Donc il suffit de récupérer la valeur désirée comme suit : local monmessage = matable.heos.message