Cardane

j'avais juste oublié un point... la sécurité par défaut le KLF-200 démarre en créant un point d'accès WIFI, qui reste disponible pendant 10 minutes par défaut. il est donc plus que conseillé de très vite rentrer dans les paramètres de configuration afin 1. de modifier le momt de passe par défaut 2. d'établir une connexion filaire 3. de supprimer cet access point Sinon votre voisin va très vite pouvoir s'amuser avec vos Velux

je ne suis pas certain de bien comprendre ton problème; mais s'il s'agit uniquement de générer un envoi de mail lors de l'ouverture de la porte, en mode block, après le "then", tu choisis l'option 'notification', ensuite tu choisis une des notifications créées dans le notification panel et ensuite le user à qui tu veux l'envoyer, et le tour est joué

Salut @pepite, merci, c'est un premier tuto, il y a certainement moyen de faire mieux mais bon, j 'ai fait pour un mieux dans les quelques heures de libre ce weekend euhhh, le VD il est franchement vide, mais si tu veux je le rajoute dans le post précédent

Pilotage des Velux Integra avec le KLF-200 et la HC2 Attention : ce tuto ne fonctionne qu'avec un KLF-200 dont la version de firmware est inférieure à la version 0.2.0.0.71.0. A partir de cette version de firmware, Velux a supprimé l'accès via http au klf-200. La bonne nouvelle, c'est que l'API est en train d'être documenté et surtout largement complété. Il y aura par contre de gros changement au niveau du protocole. J'attends la finalisation de la nouvelle version et de la documentation et je reviendrai mettre à jour ce post. Présentation Le but de ce tuto est d’expliquer comment réaliser l’interface entre le KLF-200 de Velux et notre HC2 Je tiens à remercier @pepite, @Lazer, @Steven, et @OJC pour leur aide dans la réalisation de la scène LUA. Merci aussi au travail d’Erlend sur community.openhab.org qui est à la base de cet article. (https://community.openhab.org/t/io-homecontrol-velux-somethings-in-the-bush/11413/30) Je dispose de plus de 15 Velux, et donc pour moi il fallait absolument trouver une solution avec laquelle je pourrais piloter l’ensemble de ces Velux à moindre coûts, et surtout le plus simplement possible. J’avais envisagé la solution de l’IPX800, mais je n’avais aucune envie de refaire des câblages supplémentaires. En plus, je disposais déjà d’une télécommande de type KLR-200 (IO-Homecontrol) qui me permettait de réaliser quelques scénarios mais non intégrable avec la HC2. Je voulais garder cette télécommande pour des questions de WAF entre autre, mais de facilité aussi. L’intégration avec la HC2 étant la cerise sur le gâteau me permettant d’intégrer les Velux dans des scénarios existants. Lorsque Velux a sorti il y a peu le KLF-200, qui est enfin une interface permettant au monde fermé de Velux de s’ouvrir (un peu) vers les autres solutions, j’ai franchi le cap. Voici le résultat de mon installation. Le KLF-200 Le KLF-200 se présente sous la forme d’un boitier de +/- 12*12*3 cm. Il est donc facilement dissimulable et est d’un poids relativement léger. Il est fourni avec l’alimentation, un câble réseau, et toute une série de câbles dont nous verrons l’utilité par la suite. Les manuels qui l’accompagnent couvrent toutes les langues possibles comme c’est toujours le cas avec Velux. Son prix sur la plupart des sites tourne aux alentours de 300 euros, mais on peut le trouver à 200 euros sur certains sites français. Velux compatibles Les Velux pour lesquels le KLF-200 est conçu sont les Velux Integra. Il s’agit des Velux avec moteur intégré, et prévu pour connecter directement tous les autres accessoires tels que les volets, les stores, les éclairages, etc. Je ne sais pas si ce module fonctionne avec d’autres types de Velux pour lesquels la motorisation et les volets ont été installés par la suite et commandés via d’autres interfaces comme le KUX110. Configuration du KLF-200 Pour une description plus complète et plus précise du boitier et de ses possibilités, il suffit de télécharger la notice du KLF-200 (recherche Google sur « KLF-200 notice ») Voici un bref aperçu La première étape est de configurer le boitier. Lors du démarrage du boitier, il est en point d’accès Wi-Fi pendant 10 minutes (modifiable dans les paramètres) mais il n’offre pas la possibilité de se connecter sur un réseau Wi-Fi existant. Le plus simple reste de le connecter via un câble sur votre réseau, il prendra alors une adresse via le DHCP. Il suffit ensuite de s’y connecter avec n’importe quel browser (Chrome, Safari, Firefox ou autre). On arrive sur la page de login, on entre le mot de passe par défaut et on choisi la langue. On arrive ensuite sur la première page qui va nous permettre d’enregistrer les différents produits. Le plus simple pour cela est de partir d’une commande existante et de lui transmettre les devices qu’elle connait. J’ai donc pris ma KLR-200, et je lui ai demandé de transmettre au KLF-200 les informations connues. De même pour les autres commandes dont je disposais. Le KLF-200 peut enregistrer 5 groupes de produits. Par exemple, il va créer un groupe pour tous les moteurs d’ouvertures, ensuite un autre groupe pour les volets, etc… Je ne sais pas s’il y a un nombre maximum d’objets par groupe, mais avec 15 ça marche. Ci-dessous, une copie d’écran après l’enregistrement des 5 moteurs de ma première pièce. Par défaut, le KLF-200 reprend les noms qui étaient configurés dans la KLR, mais on peut éditer chaque device et modifier ce nom. Si vous cliquer sur le petit icône bleu, le KLF-200 active l’objet en question pendant quelques instants, ce qui vous permet de vérifier qu’il s’agit bien du bon . Ensuite, en choisissant le menu “Programmes”, on peut commencer à créer autant de programmes que l’on veut. Un programme est une suite d’actions sur un ou plusieurs devices. On peut par exemple créer comme ci-dessous un programme qui ouvre tous les Velux à 100%, un autre qui ferme tous les Velux, un autre qui les ouvre tous à 50%, mais aussi par exemple un programme qui va ouvrir deux Velux à 100%, un troisième à 50% qui va baisser le volet d’un quatrième positionner le store d’un cinquième à mi-hauteur. Pour ce faire, le KLF-200 se met en mode enregistrement, et avec une autre télécommande vous actionner vos devices comme vous le voulez. Une fois fini, on arrête l’enregistrement et le tour est joué. Ci-dessous un exemple de 5 programmes pilotant les 5 moteurs des Velux d’une même pièce. La dernière étape est la configuration des entrées/sorties. Comme expliqué ci-dessous, je n’ai pas choisi cette option, préférant utiliser l’appel à l’API, mais le KLF-200 dispose à l’arrière d’une série de connecteurs, qui permettent de réaliser des contacts secs (donc possible via un module Fibaro). L’activation d’un contact sec permet soit de modifier la position d’un produit, soit de basculer entre deux positions, ou enfin d’exécuter un programme. Plus intéressant, la possibilité de récupérer le statut d’une action. Toujours à l’arrière du boitier, on trouve 5 paires, chacune pouvant établir un contact sec suivant la configuration demandée. On peut donc ici aussi connecter un module Fibaro afin de récupérer cette information et l’utiliser dans nos scenarios. (Pour l’instant je ne l’ai pas encore fait, je suis toujours en phase de réflexion sur ce qui me sera le plus utile). Fonctionnement du KLF-200 via l’API Le KLF-200 est conçu à la base pour être piloté via les connections câblées présentes à l’arrière du boitier comme expliqué ci-dessus MAIS, il y a aussi un API REST non documenté et non supporté qui permet d’exécuter directement certaines commandes. C’est cette option que j’utilise actuellement car beaucoup plus simple et surtout moins chère.(moins de modules) Il n’y a aucune description de cet API, je suis donc parti de l’exemple réalisé par « Erlend » Les points faibles 1. Il n’est pas possible de contrôler un seul device directement, il faut passer par un programme (ou alors personne n’a encore trouvé comment le faire) 2. Il n’est pas possible via l’API de connaître la position d’un produit 3. Il n’est pas possible de créer un programme directement via l’interface web, il faut toujours passer par le mode enregistrement, ce qui peut être fastidieux. Il est possible de faire une mise à jour du firmware, mais à ce jour je n’ai toujours pas trouvé de nouvelle version, et comme l’API n’est pas documenté, impossible de savoir si de nouvelles fonctions sont disponibles. Configuration de la HC2 Du côté de la HC2, j’ai donc simplement une scène et VD, qui permettent de piloter l’ensemble. La scène englobe l’appel au KLF-200, via l’API, et le VD permet d’appeler la scène avec passage de paramètres (l’adresse IP du boitier et le programme que je veux exécuter) Chaque fois que l’on désire exécuter un programme sur le KLF-200, cela se passe en trois étapes. Il faut commencer par un LOGIN, qui va retourner un token. Ensuite un deuxième appel (en passant ce token en paramètre) qui demande au KLF-200 d’exécuter une action, et enfin un LOGOUT. On peut bien entendu exécuter plusieurs actions entre le LOGIN et le LOGOUT. L’idéal est de travailler en mode asynchrone, car certaines actions peuvent prendre du temps du côté du KLF-200. La scène Il y a certainement beaucoup d'améliorations à faire dans ce code, mais je n'ai pas eu trop le temps d'y retravailler depuis que cette première version fonctionne. Pendant les fêtes de fin d'année je devrais avoir un peu de temps pour y regarder --[[ %% properties %% events %% globals --]] -- les variables globales ci-dessous sont initialisées avec des valeurs par défaut -- ces valeurs seront normalement écrasées par le passage de paramètres lors de l'appel de la scène. local VeluxDebug = true local programme = "2" local password = "xxxYYYzzz" local KLF_ip = "192.168.yyy.zzz" local params = fibaro:args() if (params) then for k, v in ipairs(params) do if (v.programme) then programme = v.programme end if (v.adresseIP) then KLF_ip = v.adresseIP end if (v.password) then password = v.password end end end local urlLogin = 'http://'.. KLF_ip .. '/api/v1/auth' local urlLogout = 'http://'.. KLF_ip .. '/api/v1/auth' local urlScenes = 'http://'.. KLF_ip .. '/api/v1/scenes' local datasLogin = '{"action":"login","params":{"password":"'.. password .. '"}}' local datasLogout = '{"action":"logout","params":{}}' local datasAction = '{"action":"run","params":{"id":"' ..programme ..'"}}' if (VeluxDebug) then fibaro:debug("Démarrage de la scène avec les paramètres suivants") fibaro:debug("adresse IP = " .. KLF_ip) fibaro:debug("Password = " .. password) fibaro:debug("Programme = " .. programme) fibaro:debug(datasAction) end local klf = net.HTTPClient() klf:request(urlLogin , { success = function(response) if tonumber(response.status) == 200 then if (VeluxDebug) then fibaro:debug("Call for LOGON successfull") fibaro:debug("Valeur de response") fibaro:debug(json.encode(response)) end -- récupération du token local temp = json.encode(response) local token = temp:match('\\\"token\\\":\\\"(.+)\\\",\\\"result') token = string.gsub(token, '\\', '') if (VeluxDebug) then fibaro:debug("Valeur du token : "..token) end klf:request(urlScenes, { success = function(response) if tonumber(response.status) == 200 then if (VeluxDebug) then fibaro:debug("Call for ACTION successful") fibaro:debug("response\n") fibaro:debug(json.encode(response)) end klf:request(urlLogout , { success = function(response) if tonumber (response.status) == 200 then if (VeluxDebug) then fibaro:debug("Call for LOGOUT successful") fibaro:debug("response\n") fibaro:debug(json.encode(response)) -- fibaro:debug("response.data\n") -- fibaro:debug(response.data) end else if (VeluxDebug)then fibaro:debug("LOGOUT Failed : Status =" .. response.status) end end end, error = function(err) print ("Erreur de LOGOUT") print('error = ' .. err) end, options = { method = 'POST', headers = { ["content-type"] = 'application/json, charset=utf-8', ["Authorization"] = "Bearer "..token, ["Connection"] = 'close', }, data = datasLogout } }) else if (VeluxDebug)then fibaro:debug("RUN ACTION Failed : Status =" .. response.status) end end end, error = function(err) print("Erreur lors du RUN ACTION") print('error =' ..err) end, options = { method = 'POST', headers = { ["content-type"] = 'application/json, charset=utf-8', ["content-length"] = "34", ["Authorization"] = "Bearer "..token, ["Connection"] = 'Keep-Alive', }, data = datasAction } }) else if (VeluxDebug)then fibaro:debug("Login Failed : Status =" .. response.status) end end end, error = function(err) print ("Erreur lors du LOGIN") print('error = ' .. err) end, options = { method = 'POST', headers = { ["content-type"] = 'application/json, charset=utf-8', ["connection"] = 'close', }, data = datasLogin } }) Le VD Je ne vais pas décrire le VD ici car il est vraiment simpliste, il contient simplement autant de boutons que d’actions que je désire effectuer et chaque bouton contient uniquement un appel à la scène en passant les bons paramètres. Si quelqu’un le souhaite je peux toujours lui envoyer en MP. Edit : comme demandé, voici le VD que j'utilise pour l'instant... il est franchement basique et sera certainement retravaillé par la suite suivant mes besoins Velux.vfib

effectivement sous Win10 tu n'as pas l'option "Afficher l'image", mais par contre tu as l'option "ouvrir l'image dans un nouvel onglet"... tu fais ca et dans le nouvel onglet, dans la barre de navigation tu retrouves le numero ou le nom de l'icône... par contre avec le toolkit tu devrais retrouver l'ensemble des icônes, pas uniquement les icônes de base

avec le toolkit, dans la lsite des devices, quand tu passe simplement la souris sur l'icône il te montre son nom... un click droit, afficher les propriétés, et la tu trouves l'ID de l'icône

est-ce que tu donné les droits pour ta scène à l'utilisateur du téléphone ?

complètement d'accord avec @Lazer, c'est le genre d'automatisation qui ne sert à rien parce que d'office en repassera en mode manuel.... du moins si c'est pour gérer des choses telles que le chauffage. Sinon, effectivement, une petite ligne GEA

suis d'accord avec @BenjyNet... une bonne entête de fonction, bien claire et obligatoire, et ca doit être suffisant. On prend le bout de code, on sait ce qu'il fait, ce qu'il retourne, ce qu'il veut en entrée, et à la rigueur on s'en fout de savoir comment il le fait. Et si on veut malgré tout le savoir, ben , on l'analyse et on essaie de comprendre, c'est comme ca que tout le monde pourra progresser en LUA Bon, après, fait pas comparer ca avec GEA ... entre GEA et un snippet de 20 lignes, il y a de la marge, et je comprends que le sujet Support GEA soit des plus utiles....

tu as bien configuré avec le fibaroID pour ta connecxion à distance ?

@pepite Salut, voici comme promis la photo de la plaque d'identification des velux.

si tu le dis je m'endormirai moins bête ce soir ;-) merci pour ton aide

@OJC bon, après quelques tests, il semble que ca fonctionne j'ai repris un bout de ton code, dont le nouveau gsub, et ca fonctionne ca ne résoudra pas tes problèmes mémoire, mais il y a au moins ca de positif aujourd'hui merci pour ton aide je vais maintenant enfin tester avec ne vraie action sur mes velux, on verra si ils restent ouverts toute la nuit...

voilà la description que j'ai trouvé... --raw-output / -r: With this option, if the filter’s result is a string then it will be written directly to standard output rather than being formatted as a JSON string with quotes. This can be useful for making jq filters talk to non-JSON-based systems. si je comprends bien, ca permet de balancer la string "brute", en mode raw, et donc il n'interprète pas les caractères de ce type

@OJC en fait il faudrait l'équivalent du jq -r qu'il utilise dans le shell script (comme j'ai mis en page 3), mais là, je ne connais pas du tout assez bien lua pour ca

@OJC toujours le même problème... en plus c'est chiant, faut que je teste 20 fois avant qu'il ne me génère un token avec un caractère comme ca

@Nico, non par contre si je dis "Dis Siri, ouvre les velux", ca marche

voici le code -- Authentification local ip = "192.168.1.33" local url = 'http://'.. ip .. '/api/v1/auth' local dataslogin = '{"action":"login","params":{"password":"velux123"}}' local dataslogout = '{"action":"logout","params":{}}' local klf = net.HTTPClient() klf:request(url , { success = function(response) fibaro:debug(json.encode(response)) local temp = json.encode(response) local key = "token" local token = temp:match('\\\"token\\\":\\\"(.+)\\\",\\\"result') string.gsub(token, "\\", "\\\\") fibaro:debug("token\n") fibaro:debug("") fibaro:debug(token) klf:request(url , { success = function(response) fibaro:debug("Je suis dans response\n") fibaro:debug("response\n") fibaro:debug(json.encode(response)) fibaro:debug("response.data\n") fibaro:debug(response.data) end, error = function(err) print ("Je suis dans err") print('error = ' .. err) end, options = { method = 'POST', headers = { ["content-type"] = 'application/json, charset=utf-8', ["Authorization"] = "Bearer "..token, }, data = dataslogout } }) end, error = function(err) print ("Je suis dans err") print('error = ' .. err) end, options = { method = 'POST', headers = { ["content-type"] = 'application/json, charset=utf-8', }, data = dataslogin } }) et voici le debug [DEBUG] 20:28:54: {"data":")]}',\n{\"token\":\"Ezm\/TjhEQwAWeEhrpWu\/YA==\",\"result\":true,\"deviceStatus\":\"IDLE\",\"data\":{},\"errors\":[]}","status":200,"headers":{"Content-Length":"100","Connection":"Keep-Alive","Content-Type":"application\/json"}} [DEBUG] 20:28:54: token [DEBUG] 20:28:54: [DEBUG] 20:28:54: [DEBUG] 20:28:54: Ezm\/TjhEQwAWeEhrpWu\/YA== [DEBUG] 20:28:55: Je suis dans response [DEBUG] 20:28:55: [DEBUG] 20:28:55: response [DEBUG] 20:28:55: [DEBUG] 20:28:55: {"data":"HTTP\/1.1 403\r\nContent-Type: application\/json\r\nConnection: Keep-Alive\r\nContent-Length: 65\r\n\r\n)]}',\n{\"result\":true,\"deviceStatus\":\"IDLE\",\"data\":{},\"errors\":[]}","status":1,"headers":{}} [DEBUG] 20:28:55: response.data [DEBUG] 20:28:55: [DEBUG] 20:28:55: HTTP/1.1 403 [DEBUG] 20:28:55: Content-Type: application/json [DEBUG] 20:28:55: Connection: Keep-Alive [DEBUG] 20:28:55: Content-Length: 65 [DEBUG] 20:28:55: [DEBUG] 20:28:55: )]}', [DEBUG] 20:28:55: {"result":true,"deviceStatus":"IDLE","data":{},"errors":[]}

@OJC re salut bon, mauvaise nouvelle, en fait dès que le token contient un caractère d'échappement, ca ne marche pas... mon test c'est d’enchaîner un login, puis un logout, donc lors de l'appel au logout je lui passe comme paramètre le token obtenu lors du login. j'ai bien rajouté le peit bout de code que tu m'as donné ci-dessus mais je reçois un access denied (erreur 403) lors de l'appel au logout. si c'est un token normal, ca marche tu as une idée ?????

Yo, je te fais ca ce weekend, (faudra que je monte à l'échelle )... mais comme de toute manière je crois que pour faire revivre ma télécommande je dois faire un reset des velux...

ah tu parles des volets toi ? moi je parle des moteurs d'ouverture des velux. Les Integra, ils arrivent avec le moteur d'ouverture et toute la connectique pour venir brancher rapidement tous les autres accessoires, comme les volets, les stores, les lampes, etc et d'office tu les retrouves sur la télécommande. en fait moi je n'ai qu'un câble d'alimentation 220v qui arrive au Velux

@pepite, pas de problème je vais essayer de faire ca dans les meilleurs délais (suis un peu débordé ce weekend mais je vais essayer) par contre tu as bien des Velux Integra ? parce que j'ai l'impression que ca ne marche qu'avec ca... ou tu as des velux que tu as motorisé par la suite ? oui, moi aussi quand le gars est venu installer les velux il avait un KUX100, mais je ne voyais pas l'intérêt d'installer ce truc puisque de toute manière ils étaient fournis avec la télécommande tactile KLR200 (celle que je viens de bousiller )

ah oui, juste, il faut que je rajoute systématiquement ce bout de code avant de réutiliser le token, merci d'y avoir pensé

merci pour l'explication

oufffff, super content, le WAF rentre ce soir, et comme j'ai bousillé l'autre télécommande en faisant mes tests, je crois que si je n'avais pas de solution via la HC2, j'aurais encore entendu parler de ma domotique tout le weekend