Lazer

Etrange ce problème..... J'ai bien quelques VD qui appuient sur des boutons au démarrage, et il ne me semble pas avoir jamais rencontré ce problème. En tout cas tant mieux si tu as une solution.

Parfait ce tuto Perso je mappe le disque en RDM sur une VM Linux Debian à coté, ça va plus vite que les complications de DSM.... m'enfin le résultat est le même normalement. Attention sur les gros disques, ça prend du temps.... ça a pris 6 jours pour mes 10 et 12 To, avec 4 passes de paterns différents (donc 8 passes si on compte la lecture et l'écriture)

Sur DSM, il y a un outil intégré qui te propose un check du disque dur au formatage.... aucune idée de ce que ça fait en vrai ! Perso j'utilise badblocks, qui fait plusieurs passes complètes sur le disque, il écrit des paterns, puis relis, pour vérifier qu'il trouve bien la même chose que ce qui a été écris. Tu fais comme tu veux pour tes volumes, mais perso je suis partisan de ne faire que des volumes simples, et je ne sauvegarde que les données qui ont besoin de l'être, chaque nuit, vers un serveur distant (protection vol/incendie) C'est d'autant plus utile dans mon cas que je n'ai que des disques de taille différente, achetés en fonction de mes besoins, des promos, et de l'évolution de la technologie des volumétries de disques. Au passage, quand on fait du RAID, il faut toujours utiliser des disques achetés séparément... Jamais un même lot, sinon tu as de grande chance que tous les disques pètent à quelques heures d'intervalles.... donc pendant la reconstruction sur le hot spare (quand y'en a un.....) Le RAID mal fait, ne protège pas la données, au contraire, il ne fait que multiplier les risques de perdre des données..... mais il est difficile de se battre contre le discours marketing de sociétés comme Synology.

Le risque de panne est devenu très rare de nos jours... un disque ça pète quand c'est neuf, ou jamais (au delà de 5 ans, normalement remplacé avant car trop petit) Je fais un stress-test de 6 jours à tous mes disques neufs pour identifier les pannes, ce qui m'a bien servi pour un WD RED 8To qui est tombé HS au bout d'une demi-journée. Renvoyé en SAV direct, j'en ai eu un neuf qui tourne comme une horloge. Le vrai risque, c'est la corruption, accidentelle (bug dans mon cas), ou erreur humaine, ou cryptolocker. D'où la nécessité des backups. Je le redis, le RAID ne sert qu'à 2 choses : - performances en multipliant les axes disques.... ce qui est valable quand dans le cas d'une carte contrôleur RAID matérielle, et donc pas dans nos NAS grand public qui font tout en logiciel.... et encore même en RAID Hardware, de nos jours ce n'est plus trop utile, un seul SSD éclate sans broncher un RAID de N disques durs ! - continuité de service => je continue à travailler pendant que le RAID reconstruit. Pour cela, encore faut-il avoir un disque de Hot Spare dédié, et de toute façon, à la maison, qui a réellement besoin de continuité de service ? Même un pro qui bosse chez lui (c'est mon cas parfois), je travaille sur le SSD de mon PC, donc avec une copie locale des données. Il n'y a qu'en entreprise, où les utilisateurs ouvrent directement les fichiers / bases de données sur le serveur, que la continuité de service est requise.

Je suis d'accord, entre 5 et 9 lux, pas trop de différence, dans les 2 cas c'est trop sombre.

tu me demandes ça à moi, mais je n'ai pas l'utilité de mesurer le soleil. je posais la question par simple curiosité On sait maintenant que même si le FGMS permet d'aller au delà de l'Everspring, cela ne suffit toujours pas pour mesurer le soleil. Après est-utile, c'est une autre question....

non c'est un nouveau bootloader, je crois que mprinfo avait donné le lien, version 1.03 ou un truc du genre Pour ESXi tu fais ce que tu veux, c'est indépendant. Perso je suis toujours en 5.5.

Mais ça c'est quand vous utilisez le VD Pour voir la table de routage, non ? C'est lui qui force le rafraichissement.

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