Lazer

J'ai l'impression que c'est comme pour Alexa, non ? Pas possible de piloter les ouvrants pour des raisons de sécurité. (Il suffit de crier depuis l'extérieur pour ouvrir les volets, voire la serrure connectée)

Cool PS : tu n'es pas sans savoir que Nice a racheté Fibaro..... quelle coïncidence !

Sinon, si tu as plusieurs volets, la solution ultime, avec retour d'état, c'est le boitier KLF 200, il y a un topic sur le forum pour sa mise en ouvre. Compter 200 à 300€, mais là tu as un vrai système interopérable, avec retour d’état, indépendant du cloud. Ce qui devrait être la norme.

Je ne dirais pas qu'elle n'est "pas bien", je dirais plutôt qu'elle ne me convient pas. IO est une technologie propriétaire et totalement fermée, conçue par le consortium Somfy / Velux / quelques autres pour enfermer le client dans un écosystème, stratégie commerciale pour conserver les clients captifs de la marque. Donc comme tu peux le constater, tu as des volets IO, donc tu es obligé d'acheter une box Tahoma pour les contrôler. C'est tout le contraire d'une domotique ouverte, interopérable, évolutive. C'est une stratégie commerciale qui se défend pour le constructeur, et qui peut lui être bénéfique (le meilleur exemple, c'est le modèle Apple). Par contre, ce n'est pas au bénéfice du consommateur, bien au contraire même.... Le bon choix aurait été de remplacer tes volets par des moteurs filaires, que tu aurais pu piloter avec n'importe quelle technologie ouverte (au hasard, des modules Z-Wave Fibaro ou Qubino). Le jour où le Z-Wave est dépassé (si ça arrive un jour), tu remplaces les modules sans toucher aux moteurs. C'est ça un système évolutif. Donc maintenant, dans ton cas, tu n'as plus le choix.... comme dis précédemment, IO = box Tahoma obligatoire. Et comme c'est Somfy, et que leur stratégie est d'enfermer l'utilisateur dans un écosystème propriétaire, il n'y a pas d'API sur la box Tahoma, donc aucun moyen facile de l'intégrer dans un système domotique ouvert et communicant. La solution, c'est ce qu'on fait les gars de Jeedom.... rétro-ingénierie pour piloter des boxes Tahoma / Connexoon en passant par le cloud de Somfy. Cela fonctionne, tant que Somfy ne renforce pas la sécurité. Et même sans cela, un panne du cloud peut arriver, empêchant d'ouvrir ses volets le matin (*)... c'est arrivé l'année dernière lors de la panne géante chez OVH, puisque le cloud de Somfy est hébergé chez OVH. (*) heureusement, l'utilisateur malin aura conservé des télécommandes murales pour piloter en manuel ses volets... ne jamais dépendre à 100% de la domotique, et toujours conserver un moyen de contrôle local et manuel. Principe général à appliquer pour tout mécanisme automatisé (chauffage, ouvrants, éclairage, etc...) Cela étant dit, pour 99% des gens, le IO convient très bien, puisqu'ils se moquent totalement de la domotique, donc un écosystème fermé ne les dérange pas, ça fonctionne, point. Le souci, c'est pour les 1% restants, qui veulent faire de la domotique, et qui trainent sur ce forum ou les quelques autres forums domotiques.

@fan-de-securité c'est ici que ça se passe

+1, les VD ne devraient pas évoluer (et n'ont pas évolué depuis des années) T'es pas obligé de passer par une scène non plus, tu peux gérer le "toggle" ON/OFF au sein même du bouton. Après tout dépend de ton code LUA.

Oui la reconnaissance vocale se fait toujours dans le Cloud de Google ou d'Amazon, les enceintes embarquées n'ont aucune puissance de calcul. Mais de ce que j'en déduis, une fois l'ordre vocal reconnu et traduit en action, la communication passe ensuite directement dans le Cloud de Fibaro, qui peut donner l'ordre à notre HC2 grâce au tunnel montant établie par notre box domotique. Donc pas d'ouverture de ports nécessaire, ni de stockage d'identifiants chez un tiers, comme dans le cas d'IFTTT. Cela me convient mieux (même si dans l'absolu, je préfèrerais une solution totalement cloud-less, mais à part l'usine à gaz Sarah, il n'y a guère de solution) Je vais ressortir mon Google Home de sa boite pour tester du coup EDIT : mais parler à "Alexa" est quand même plus naturel et humain, donc WAF/HAF. Elle a été tellement bien accueillie, que maintenant quand on est dans un lieu public, ma fille demande naturellement à Alexa d’allumer la lumière

Bien, c'est donc comme avec Alexa si je comprends bien

Et le langage est naturel comme avec Alexa ? Ou il faut toujours demander à Google "de demander à Fibaro" d'allumer la lumière ?

Remplacer : if today ~= date then msg = msg .. " " .. date end Par : msg = msg .. " " .. date (donc en fait, juste supprimer la condition) EDIT : j'en déduis à la lecture de l'autre topic que tu utilises une vieille version totalement dépassée, tu ferais mieux de relire ce topic, et en particulier cette page-ci.....

Euh, le Broadcast, bien au contraire, va saturer ton réseau bien plus vite que plusieurs connexions Unicast. Le Broadcast doit être évité à tout prix, et réserver à certains usages indispensables (typiquement sur un LAN, les requêtes ARP Who Has) Mais surtout pas de broadcast pour de la communication régulière entre plusieurs équipements. C'est pour cela que le Multicast a été inventé.... Rend toi compte : 2 équipements qui discutent ensemble => 1 trame unicast point à point 1 équipement qui communique vers tout ton réseau => 1 trame broadcast multipliée par le nombre de ports sur les switchs de ton réseau... sur un switch 8 ports ça va, sur un gros réseau ça va faire mal....

l'intérêt de cette API est de limiter le trafic en ne notifiant que les changements depuis le dernier polling regarde, tu comprendras. Pour ta dernière question, je ne connais rien au Multicast, je suis incapable de te répondre.

oui, c'est du polling, donc interrogation régulière en français. pour le reste, à toi de comprendre.... en utilisant les outils de débug de ton navigateur perso je n'ai jamais utilisé.

Tu pourrais faire comme l'application mobile ou l'interface Web, à savoir faire un polling chaque seconde avec l'API dédiée prévue par Fibaro : /api/refreshStates Par contre, bon courage pour comprendre comment l'utiliser....

En fait mon code est dans une mainloop, comme ça toutes les 5 Minutes je check si la variable existe, et le script la récrée automatiquement si nécessaire.... utile si l'utilisateur efface une VG par erreur.

Petit extrait de l'un de mes VD : local VG = { ["toto"] = {['default']='valeur', ['enum']={}}, ["titi"] = {['default']='', ['enum']={}}, } local debug = false -- -- createVG() -- local createVG = function(varName, varValue, varEnum) local isEnum = (#varEnum > 0) and 1 or 0 local HC2 = Net.FHttp("127.0.0.1", 11111) local payload = '{"name":"'..varName..'","isEnum":'..isEnum..',"value":"'..(varValue or "")..'"}' local response, status, errorCode = HC2:POST("/api/globalVariables/"..varName, payload) if tonumber(errorCode) == 0 and (tonumber(status) == 200 or tonumber(status) == 201) and response ~= nil and response ~= "" then fibaro:debug('Global variable "'..varName..'" created') if isEnum > 0 then local payload = '{"name":"'..varName..'","isEnum":true,"enumValues":'..json.encode(varEnum)..'}' local response, status, errorCode = HC2:PUT("/api/globalVariables/"..varName, payload) if tonumber(errorCode) == 0 and (tonumber(status) == 200 or tonumber(status) == 201) and response ~= nil and response ~= "" then fibaro:debug('Global variable "'..varName..'" modified with enum values') else fibaro:debug('Error : Can not modify enum global variable, errorCode='..errorCode..', status='..status..', payload='..payload..', response='..(response or "")) end end else fibaro:debug('Error : Can not create global variable, errorCode='..errorCode..', status='..status..', payload='..payload..', response='..(response or "")) end HC2 = nil end -- -- checkVG() -- local checkVG = function(VG) local vg, param for vg, param in pairs(VG) do if debug then fibaro:debug("Check if global variable '"..vg.."' exists") end local response = api.get("/globalVariables/"..vg) if type(response) == "table" then if not response.name or response.name ~= vg then if debug then fibaro:debug('Response OK but global variable "'..vg..'" does not exist...') end createVG(vg, param['default'], param['enum']) end else if debug then fibaro:debug('Global variable "'..vg..'" does not exist...') end createVG(vg, param['default'], param['enum']) end end end -- Check if global variable exist checkVG(VG)

Je reconnais que Fibaro met le paquet ces derniers temps, le rachat par Nice les motive grave !!! Par contre, là c'est IFTTT quoi, un service dépendant du Cloud, qui demande d'ouvrir un port de la box sur le Web, et de stocker les identifiants chez eux. Chacun son truc, je sais que IFTTT est la solution de facilité hyper à la mode partout dans le monde des objets connectés, mais perso je passe mon tour.

Euh désolé je n'ai pas de Tahoma, et je prie tous les soirs pendant 1h de ne jamais en avoir besoin. Mais il y a des tutos, cherche sur Google, en tout cas il y a pas mal d'utilisateurs de la Tahoma ou Conexxoon en passerelle chez Jeedom et eedomus.

voilà, tu as compris

@Nicoouais pas contre si tu éteins la box proprement un peu avant que la batterie de l'onduleur soit à plat, mais que le courant revient entre temps, alors la carte mère ne voit jamais la coupure de courant, donc ne redémarre jamais, d'autant plus qu'il est impossible de la redémarrer par WOL. D'où la solution de @J3R3M de rajouter une prise commandée (autonome (*)) pour forcer la coupure de courant en complément. Bon de toute façon, l'idéal c'est de ne jamais avoir de coupure de courant, perso j'ai une alimentation secourue pour la HC2, indépendante de l'onduleur, avec une autonomie record de plusieurs heures. (*) euh, on est d'accord sur la fait qu'elle doit être autonome, type 3G/4G, etc. (vous avez posté entre temps)

normalement si, même proprement éteinte, le fait de débrancher la prise, puis la rebrancher, suffit à démarrer automatiquement la carte mère. C'est configuré ainsi dans le BIOS par défaut sur toutes les HC2. Note que le branchement/débranchement doit être suffisamment long pour que les condensateurs puissent se décharger, afin que la carte mère se "rende compte toute seule" de la perte d'alimentation. Si on le fait trop vite, elle ne "voit" rien, et la box ne redémarre pas seule. Donc dans le cas d'une prise programmable (valable aussi pour l'action manuelle de tirer sur la prise), il faut attendre plusieurs secondes.... Aucune idée de combien, faites des tests, puis doublez cette valeur par sécurité.

Bienvenue sur le forum Alexandre. Merci pour ces infos. Oui continuons la discussion technique sur le topic dédié :

Je ne savais pas qu'on avait un représentant de Viaroom sur le forum, merci pour les infos PS : les liens ne sont pas clicables. Dommage, on n'a toujours aucun liens vers cette solution pour le visiteur de passage

Domadoo a fait un article très récemment sur les nouveautés de cette box. Mon analyse personnelle, c'est qu'à la lecture des nouveautés, cette box ne savait quasiment rien faire à sa sortie, et qu'elle reste encore ultra limitée aujourd'hui. Mais ce n'est que mon avis, et comme tu dis, je fais partie de ceux qui préfèrent régler mes propres automatismes.

En ne citant pas le message immédiatement précédent Plus sérieusement, en cherchant, je ne connais pas tes codes LUA, tu dois en avoir un qui fait des appels en loopback (127.0.0.1 sur le port 11111) avec authentification, alors que c'est inutile dans ce contexte.