Aller au contenu

Lazer

Administrateur
 Afficher le profil  Afficher son activité

  • Compteur de contenus

    26 173

  • Inscription

  • Dernière visite

  • Jours gagnés

    1 318

 Type de contenu 

Tout ce qui a été posté par Lazer

  1. Lazer
    Merci
  2. Lazer
    Qu'on puisse ajouter le champ de données quand on envoie une requête de type POST (après tout, ça sert justement à ça le POST, contrairement au GET qui est conçu pour uniquement recevoir des données) Par la même occasion, ça ne couterait rien qu'il ajoutent la possibilité de faire des requêtes PUT.
  3. Lazer
    Tu peux mettre à jour le premier post avec les infos de l'URL ? Les exemples ? Facile, n'importe quel appareil externe (sauf l'IPX donc, en attendant que GCE ne fasse évoluer son firmware) Cela peut être une box domotique utilisée en passerelle (au hasard, Jeedom, FHEM, Zibase, etc), des scripts Shell (CURL), des pages Web (PHP), etc, la liste est infinie. Mais tu n'as pas à préciser ces infos, c'est aux utilisateurs de faire en fonction de leurs besoins, le premier post est juste là pour donner la syntaxe de l'API, et c'était la demande initiale de Nico je crois.
  4. Lazer
    Euh, doucement quand même, l'implémentation EnOcean de GCE Electronics est partielle, tous les modules EnOcean ne sont pas reconnus. En tout cas c'est ainsi pour l'extension de l'IPX800 v4, donc je pense qu'il en est de même pour l''EcoDevices RT. Donc il faut vérifier avant achat selon les modules que tu veux piloter.
  5. Lazer
    Si c'est du https, et que la boite vérifie le certificat (ce que j'espère pour des raisons de sécurité), tu ne pourras même pas générer ton propre certificat auto-signé et intercepter les communications. Il ne reste plus qu'une seule solution, faire du "scraping", c'est à dire ouvrir la page web et te balader dedans pour extraire les informations qui t'intéressent, via un script (en LUA si possible, sinon via un script externe hébergé ailleurs) Autre approche possible : il existe une appli Android, il serait intéressant de voir comment elle se connecte au serveur cloud, peut-être que tu peux tenter une approche de ce coté là.
  6. Lazer
    Si il ne précise rien, c'est que c'est du GET par défaut, donc tu ne pourras pas démarrer une scène avec des arguments directement depuis l'IPX. Tu as une v3 ? Je viens de vérifier sur mon IPX800 V4, on peut bien faire du GET et du POST, mais il ne permet pas d'insérer le champs de données, donc le POST ne sert à rien..... pfff dommage, faudrait remonter l'info à GCE
  7. Lazer
    Non je ne sais pas, si @Krikroff ou @Steven passent par là, ils pourront peut être te renseigner.
  8. Lazer
    @MAM78 tu peux mettre en premier message, l'info est fiable car extraite des sources de Fibaro. C'est Jacques qui se trompe dans la config de l'IPX je pense, à cause de la limitation de l'IPX.
  9. Lazer
    rassure moi, tu fais bien du POST comme je l'ai indiqué ? Car là tu me présentes des requêtes GET, donc forcément, ça ne va pas marcher.... j'ai un doute, je crois que l'IPX ne sait pas faire de POST, mais que du GET et du PUT. Tu confirmes ?
  10. Lazer
    tu peux développer ? c'est quoi le problème ? je pensais justement à l'IPX, j'avais édité mon message entre temps
  11. Lazer
    Je confirme, voici les infos : URL à appeler en POST : /scenes/123/action/start Données à envoyer en POST : {["args"]=args}) @MAM78 je pense que tu peux ajouter cette info dans le premier message, ça peut être utile pour ceux qui désirent lancer la scène depuis un appareil externe, tel qu'un IPX800 ou autre.
  12. Lazer
    Super VD, merci Je déplace dans la catégorie Tutos du coup !
  13. Lazer
    Donc cela nous laisse à penser que ce n'est pas de l'association directe entre modules Z-Wave, et que tu dépends de ton contrôleur domotique. On en revient toujours à la même limitation du firmware de FGS.
  14. Lazer
    J'ai séparé tes 2 messages dans un nouveau topic de travail dédié à SYSLOG. Dans une scène je ne sais pas, mais dans un VD j'utilise Net.FTcpSocket() Attention à la fonction Net.FUdpSocket(), elle est bugguée, ou plutôt incomplète, car elle ne permet que d'écrire et ne permet pas de lire sur la socket UDP. J'en avais parlé sur le topic Onduleur Eaton, d'ailleurs tu y trouveras des exemples d'implémentation dans le code source LUA de la classe SNMP.
  15. Lazer
    J'ai déjà eu du Non Configuré, avec des modules récents... chez Aeotec je crois, avant que ça ne soit supporté par la HC2. Probablement des classes Z-Wave qui ne sont pas reconnues au moment de l'inclusion.
  16. Lazer
    Oui c'est du cloud uniquement, c'est ce que je disais, et c'est vraiment dommage. Le port n'est pas forcément utilisé en tant que protocole X11, il faudrait faire une analyse protocolaire avec Wireshark (sniffer) Le clavier est dedans, avec une tempo, car on s'en sert aussi pour mettre l'alarme en mode présence la nuit.
  17. Lazer
    Ah oui en effet....
  18. Lazer
    Je dirais que tu as fait le choix de la raison avec ces modules Qubino Pour moi il n'y a aucun souci de compatibilité, juste une absence de template sur la HC2 qui ne gêne en rien le bon fonctionnement. Les miens (première génération) fonctionnent parfaitement depuis le premier jour (précommande chez Pascal à l'époque) L'avantage, c'est que ces modules participent à ton maillage Z-Wave et évite de se disperser dans de multiples protocoles, plus difficile à maintenir. Le EnOcean, pour avoir essayé, j'y crois de moins en moins, les promesses marketing ne sont pas respectées en pratique (portée mauvaise, pas de maillage, récupération d'énergie pas au point (solaire ou mécanique)) J'attends plutôt de voir ce que ça donnera avec leur projet commun de Zigbee 3.
  19. Lazer
    Franchement je n'ai pas le temps, car ça représente pas mal de travail à mon avis. Il faut trouver les spécifications du protocole Syslog, pour voir à quoi ressemble les trames, et ensuite coder cela en LUA.
  20. Lazer
    Tu as les propriétés suivantes dans le JSON des modules : type baseType
  21. Lazer
    Les miens sont "non configurés" depuis 1 an et demi, ça n'empêche pas le bon fonctionnement, je n'y prête plus attention à l’icône bleue en haut. Tinman avait donné la solution pour supprimer les notifications, il faut la retrouver sur le forum.... Mais dis moi Benjy, tu as l'air indécis, un coup tu parles de piloter les fil-pilotes en EnOcean, un coup avec l'Ecodevices RT, un autre coup avec les montages électroniques de Nicolas F., puis finalement tu reprends des Qubino !!!
  22. Lazer
    PS : ton message est difficilement lisible, pense à mettre les balises <> (bouton sur la barre d'outil de l'éditeur) autour de ton code LUA. Réponse : oui c'est correct. Pour le delay, il suffisait de mettre la valeur 0 ce qui t'aurais évité de modifier toutes les lignes, mais le résultat est le même. Attention à ne pas confondre le délai (delay) et le rafraichissement, car ce n'est pas cette scène qui le gère, mais le VD Freebox de Krikroff. Le délai, c'est juste à partir de quand on prend la décision de décider si l'utilisateur est présent ou absent. Comme je le disais dans le premier post, je considère qu'un délai trop faible n'est pas fiable, mais tu fais comme tu veux, tu expérimentes et tu verras bien si les fausses détections te conviennent ou pas.
  23. Lazer
    Très mauvaise idée d'écrire sur la clé, tu vas la tuer, ce n'est pas fait pour écrire des logs.... pour info, les logs de Linux Raspbian sont ce qui tue les cartes SD sur les Raspberry PI. De toute façon, tu ne peux pas car : - la clé est démontée en temps normal depuis plusieurs firmware - il faut être root pour y accéder La meilleure solution est d'envoyer les logs sur un serveur externe. Si t'es motivé, tu crées une scène qui génère des logs au format standard syslog, et tu pourras envoyer vers n'importe quel Linux (y compris les Synology). Là c'est propre et professionnel.
  24. Lazer
    Certainement, faudrait trouver l'API en question. Mais ça doit être faisable, vu que quasiment toutes les fonctions LUA appellent l'API http
  25. Lazer
    Pour simuler le retour de la fonction, il faut faire une boucle While qui lit la variable globale et n'en sort que quand le retour est celui attendu. En n'oubliant pas de mettre un timeout au cas où la scène plante et ne met jamais à jour la variable globale. J'ai déjà un VD (jamais partagé car spécifique à mon usage) qui fonctionne sur ce principe. Exemple : local debug = true -- or false local sceneID = 20 local returnVGname = "variable_globale_de_retour" local expectedReturnValue = "OK" local Max_Elapsed_Time = 60 -- seconds -- Call scene figaro:startScene(sceneID, {{vg = returnVGname}, {param1 = "Valeur 1"}, {param2 = "Valeur 2"}}) -- Wait scene execution local startTime = os.time() while true do if debug then Message("gray", "Waiting...") end local returnVG = fibaro:getGlobalValue(returnVGname) if returnVG == expectedReturnValue then Message("green", "Scene finished with success") break elseif returnVG == "Fail" then Message("red", "Scene failed") fibaro:abort() end local elapsedTime = os.difftime(os.time(), startTime or 0) if debug then Message("gray", "Elapsed time : " .. elapsedTime) end if elapsedTime > Max_Elapsed_Time then Message("red", "Scene timeout") fibaro:abort() end fibaro:sleep(30*1000) -- Wait 30 seconds end A customiser pour vos besoins, mais c'est une trame de départ.
×
×
  • Créer...