Lazer

De mon coté j'ai eu un gros crash cette semaine.... Plantage de la carte controleur SAS b120i du Gen8. Tous les disques inaccessibles (SSD datastore, et HDD mappés en RDM). Corruption de tous les file-systems qui étaient en cours d'écriture. Une seule VM touchée, un fsck a suffit à la redémarrer. Au niveau de DSM et de ses disques mappés en RDM, c'était l'hécatombe.... le volume système (miroré sur tous les disques) était totalement mort.... comme quoi le RAID ça ne sert à rien, puisque la corruption a été répliquée sur tous les disques. Le volume1 aussi (écriture de base SQL, enregistrement caméras, downloads en cours). Les volumes sans activité (films de vacances, tout ça), n'ont pas été touchés. Bref, réinstallation totale de DSM, puis restauration depuis les backups du 2nd serveur.... ça a pris pas loin de 48h (le Gen7 penne énormément sur la lecture des millions de petits fichiers) Conclusion, une fois de plus je le redis, le RAID ça ne sert à rien pour notre usage domestique. Les sauvegardes sont indispensables. Du coup, mprinfo a posté entre temps, mais si j'avais su j'aurais peut être dû réinstaller directement en DSM 6.2

Si tu veux un boitier autonome, pas trop le choix. Sinon Legrand EcoCompteur, mais plus ou moins le même tarif je crois. Ou alors trouver un Eco Device v1 d'occasion....

C'est un module USB.... Donc connecté sur une box domotique qui le supporte

Si tu le branches sur une box domotique qui le supporte, oui. La eedomus par exemple, et sûrement aussi Jeedom.

Ça doit être lié au reformatage, tu sais, ça t'avais fait pareil à chaque recovery.

J'utilise principalement les scène pour tout ce qui doit être autonome (déclenchement avec les triggers) et ne nécessite pas d’interactivement avec l'utilisateur (pas d'affichage via les labels d'un VD). Exemples : - GEA - réveil matin (allumage progressif lumière et musique) - sonnette (envoie screenshot caméra par email) - gestion des sauvegardes les nuits - détection de présence Wifi - Watchdog (surveiller les autres VD et scènes plantés) - remonter des infos depuis l'IPX800 vers des variables globales ou Fake devices - etc Pour tout ce sur quoi je dois agir ou qui me donne un retour d'état visuel => VD - tous les équipements multimédia / home-cinéma / audio - chauffage - derniers événements - top 10 power - etc

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