Cardane

voila, tout à fait, le sud de la Belgique, l'ouest du Luxembourg et l'est de Paris... mais le Nord de rien @PITP2, mouais, c'est bien ce que je pensais, je pourrai jamais encastrer ce truc dans le poteau, il n'y a rien pour le faire tenir merci pour les photos, plus qu'à le voir en vrai lundi ;-)

@pepite du NORD ?????? euhhh, tu parles de qui ???? on n'est pas dans le Nord nous ... et puis c'est pas beau d'être jaloux

@PITP2 suis en mission à l'étranger je rentre demain soir, donc ca va être difficile pour ce weekend sinon lundi ca pourrait le faire vers 11.00 ou 14.00, peu importe

ok vendu lundi ?

dommage qu'il n'y a que des relais pour commander une ouverture... moi j'ai besoin d'un contact sec et vu leur doc, suis pas certain que le boitier tienne dans un poteau creux de portai @PITP2, si tu as le temps, tu pourrais mettre une petite photo de ce boitier, ou me dire comment il se fixe ? mercil

pas besoin de redémarrer pour ca... tu crées la scène, tu choisis l'option qui permet de la démarrer automatiquement au reboot, et puis tu la démarres à la main la première fois

ah non, pas normal du tout ... tu dois la redémarrer pourquoi ?

@jojo, oui, c'est ce que je ferais aussi, mais il dit qu'il a essayé avec Breached et que rien ne se passe...

ben moi j'essaierais avec toutes les options de Breached... Breached c'est quand tu ouvres la porte et que le contact est ouvert, après il faut voir si ton capteur est en mode armé ou pas donc normalement Breached doit fonctionner tu as essayé avec un autre capteur ? je ne sais pas si @jojo a une autre idée, mais là je ne vois pas

et si possible une copie d'écran des options de la boite de dialogue verte (les options possibles) je ne les connais pas par coeur

pas normal... je ne suis pas devant la box, et je n'utilise pas les scènes blocs, mais c'est que tu as un autre problème dans la construction de la scène bloc.... tu peux faire un print screen et la mettre ici ?

tu as essayé avec "Breached" ?

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...