Lazer

Regarde dans la doc, je ne l'ai plus sous les yeux, mais cette valeur ne doit pas descendre en dessous d'un autre paramètre. Perso je crois que je suis descendu à15s sur mes capteurs.

Absolument, il faut que tu réduises le paramètre 6 du FGMS "MOTION ALARM CANCELLATION DELAY"

Le datastore, c'est juste un conteneur, c'est à dire un filesystem qui contient les disques virtuels des VM (ce que tu appelles des "images de VM"). Donc si tes VMs ne font rien => aucune activité sur le datastore Si tes VM font beaucoup d'I/O => grosse activité sur le datastore. Donc le datastore ne prend pas de volume, puisque c'est un conteneur. Ta question c'est comme demander si le disque dur de ton PC prend du volume. Tout dépend de ce que tu mets dedans, pas plus compliqué. Bref, comme un PC normal, sauf que c'est virtualité (c'est à dire que plusieurs machines virtuelles tournent sur le même hardware). de toutes façon c'est simple, le datastore sur USB ,n'est pas supporté, donc c'est disque SATA/SAS obligatoirement (HDD, SSD) Tu devrais vraiment te lancer avec ton matos actuel pour bien comprendre, tu verras c'est tout simple et limpide. Là tu te fais des noeuds au cerveau....

je pense que t'as pas encore bien compris : le boot de ESXi c'est sur la clé USB ou la carte SD. Donc une fois booté, ce support de sert plus. 4 Go suffisent. Le datastore (dont le disque de tous les OS que tu vas virtualiser) est sur SSD ou disque dur, et c'est bien làqu'il y a une différence de perfs. Mais essaye avec le matos que tu as, tu verras bien si ça te convient ou pas, il sera toujours possible de migrer d'un datastore àun autre plus tard.

t'as intérêt d'arrêter les VMs dans le bon ordre !!!

ah, c'était pas clair Donc si tu veux mettre sur une clé USB le boot d'ESXi et un Datastore, alors la réponse est non, ce n'est pas supporté. Tu trouveras sur le net des bidouilles infames pour le faire, mais c'est très instable, et crashera tot ou tard (car les clé USB ne sont pas prévues pour supporter un grand nombre d'écriture). différence hdd vs ssd pour le datastore : exactement la même que pour le boot de ton OS sur ton PC. La différence est juste phénoménale. Tu as des SSD à vraiment pas cher maintenant, pas la peine de prendre du haut de gamme si tu n'as pas le budget. Sinon, pour débuter, ton disque de 320 Go ira très bien, j'ai tourné avec un 250 Go pendant 6 mois et ça fonctionnait très bien (que des VM Linux, donc beaucoup plus léger que des VM Windows très gourmandes) Après tu verras bien si ça te suffit ou pas.

Regarde le tuto tu trouveras réponse : http://www.domotique-fibaro.fr/index.php/topic/1277-nas-synology-dsm-5-sur-serveur-hp-n54l-vmware-esxi-55/ Mais en gros : - micro SD ou clé USB : Boot ESXi - SSD ou disque dur : datastore ESXi - les autres disques : mappés en RDM sur la VM "NAS" (Xpeno ou autre)

j'utilise le montage de datastore en NFS depuis la VM Xpeno quand j'ai besoin de monter un ISO pour installer un produit. C'est temporaire, mais ça fonctionne très bien. Evidemment tu ne fais pas tourner des VM en prod dessus, mais pour du test ça va bien.

merci Hansolo mais hum hum..... le site de netatmo donne les précipitations sur 1h, tandis que le plugin FIbaro les donne sur 10 minutes. Dans les 2 cas, je ne vois pas bien quelle genre de requête simple je pourrais faire pour calculer le total journalier. Si je fais une somme, que je divise par 10, en partant du principe qu'on a exactement 10 valeurs par tranche de 10 minutes, est-ce que ça serait précis ?

Je suis surpris.... personne n'a encore réclamé le changement d’icône, pourtant très apprécié

ah ça progresse on dirait que c'est remis à0 toutes les 10 minutes non ? Ca doit donner un graph bizarre.

128 Go oui c'est ce que j'ai sur mes 2 serveurs. Ca suffit généralement. Hum oui le verrouillage de la porte est nul sur le G8, car il faut ouvrir le boitier. Sur le G7 c'était un clé en façade, plus pratique.

Regarde sur Github, tu as le code source de chaque bouton dans des fichiers séparés.

Pour la remote console, j'utilise l'applet Java car chez moi non plus le .NET ne fonctionne pas, et j'ai pas cherché pourquoi. Le SSD, c'est pour le datastore d'ESXi donc à toi de voir la taille dont tu as besoin. Si tu n'as que des VM Linux, ça ne prend pas de place, si tu mets des VM Windows, ça bouffe un max !!

En partageant ce module, j'étais certain que vous auriez tous des idées plus tordues les unes que les autres Ma vision des choses : ce module ne remplace par le VD Check Internet, car :il n'est pas capable d'agréger plusieurs sites web pour prendre une décision (Google n'est pas suffisant, il peut être indisponible, tandis que la connexion internet fonctionne encore) La durée d'interrogation est fixe pour tous les devices surveillés. Surveiller une connexion ADSL toutes les minutes a du sens, tandis que surveiller un Sonos toutes les minutes est contre-productif (charge réseau....) Au sujet des variables globale :je ne suis pas pour créer un tableau, car comme dis Jojo, c'est impossible à exploiter dans GEA, ce qui représente quand même la majorité des usages, n'en déplaise à ses détracteurs. l'idéal est une variable globale par élément à surveiller, de façon optionnelles. Donc dans le tableau DEVICES, il suffit d'ajouter une colonne qui contient nil ou le nom de la variable globale à mettre à jour. Ainsi on peut surveiller les éléments critiques, et ignorer les autres. C'est relativement facile à implémenter. Idéalement, dans le futur, il faudrait ajouter un intervalle variable pour chaque device à surveiller, mais cela oblige à revoir la structure de tout le code, donc ce n'est pas à l'ordre du jour.

Tu montes cette image ISO comme un virtual mount point via l'ILO. Tu bootes dessus. Et tu fais l'installation sur la carte micro-sd.

SI la valeur n'est mise àjour que dans les événements, mais pas de la module lui-même, ni son JSON, ça ressemble àun gros bug. Personne n'a constaté ce point précédemment ? En tout cas, je ne vois pas comment intégrer ça dans les graphs. Car interroger le panneau d'événements, c'est pas gérable....

En fait c'est un VD que j'avais commencé il y a longtemps, et que je viens seulement de terminer, afin qu'il soit partageable à peu près proprement (même si la configuration de la variable DEVICES n'est pas des plus simples). Le but premier n'était pas de monitorer l'accès à Internet, mais il se trouve que ça fonctionne très bien avec Google par exemple. Le VD Check Internet a au moins un avantage, c'est de mettre à jour une variable globale indiquant le status de la connexion Internet, utilisable dans des scénarios.

je ne dirais pas le contraire.... sauf pour le budget, car les modules en KNX c'est pas le même prix !

Merci mais euh... ça c'est embêtant... ce sont mes yeux, où je vois des 0 partout ? dans l'interface web, tu vois bien une valeur ? Il va la chercher où alors ?

bouhhh Maintenant qu'il pleut, tu peux me redonner le JSON de ton device "pluie" ? Mon code ne doit pas prendre en compte la bonne valeur.

toi t'as pas lu le tuto j'ai bien indiqué que j'ai changé les IP (et même certains ports) pour les SMS : http://www.domotique-fibaro.fr/index.php/topic/2902-gateway-sms-autonome/

Network Monitor Version 1.20 Voici un module virtuel permettant de surveiller plusieurs équipements sur le réseau local (et aussi sur Internet), et d'envoyer des notifications en cas de problème détecté. Icônes : Je propose ces 2 icônes, mais d'autres icônes sont disponibles dans les pages du topic : Configuration : Après import du module virtuel, modifier la section "User Variables" du 1er bouton du module virtuel : -- User variables local userID = {5} -- Mail local smartphoneID = {73, 127} -- Push local sms = { ["VD_ID"] = 98, -- Virtual Device ID ["VD_Button"] = "1", -- Virtual Device Button ["VG_Name"] = "SMS" -- Global Variable Name } local icons = { ["OK"] = 1028, -- Normal Icon ID ["Error"] = 1045 -- Error Icon ID } local DEVICES = { -- ["Service Name"] = { IP Address , Port, Protocol, Data to send, Expected return code, Expected data, Retry, {Notification methods}, VG, VG }, ["Eco-Devices"] = {"192.168.1.1", 80, "http", "/index1.htm", 200, "Eco Devices" , 1, {"push", "email", "sms"}, nil, nil}, ["HP ProLiant Remote Access Card"] = {"192.168.1.2", 80, "http", "/login.html", 200, "Remote Access Card" , 1, { "email" }, nil, {"Vacances", "1"}}, ["HP ProLiant Gen8 ILO"] = {"192.168.1.3", 443, "tcp", "", nil, "" , 1, { "email" }, nil, nil}, ["ESXi"] = {"192.168.1.4", 80, "http", "/", 301, "" , 1, {"push", "email", "sms"}, nil, nil}, ["Synology DiskStation"] = {"192.168.1.5", 5000, "http", "/webman/index.cgi", 200, "DiskStation" , 1, {"push", "email", "sms"}, nil, nil}, ["Raspberry PI"] = {"192.168.1.6", 80, "http", "/", 200, "Welcome to nginx" , 1, {"push", "email", "sms"}, nil, nil}, ["Sonos"] = {"192.168.1.7", 1400, "http", "/status", 200, "Options" , 1, {"push", "email" }, nil, {"Vacances", "1"}}, ["SMS Gateway"] = {"192.168.1.8", 9090, "http", "/", 200, "Welcome to SMS Gateway" , 5, {"push", "email" }, nil, nil}, ["VRT-IP"] = {"192.168.1.9", 80, "http", "/", 200, "Volets Roulant de Toit" , 1, {"push", "email" }, nil, nil}, ["IPX800"] = {"192.168.1.10", 80, "http", "/user/index2.htm", 200, "IPX800" , 1, {"push", "email" }, nil, nil}, ["Foscam"] = {"192.168.1.11", 88, "http", "/", 200, "IPCam Client" , 1, {"push", "email", "sms"}, nil, {"Vacances", "0"}}, ["Hikvision"] = {"192.168.1.12", 80, "http", "/doc/page/login.asp", 200, "login" , 1, {"push", "email", "sms"}, nil, nil}, ["HAproxy"] = {"192.168.1.13", 80, "http", "/", 503, "" , 1, {"push", "email", "sms"}, nil, nil}, ["FHEM"] = {"192.168.1.14", 8083, "http", "/fhem", 200, "EnOcean" , 1, {"push", "email", "sms"}, nil, nil}, ["Freebox"] = {"192.168.1.15", 80, "http", "/login.php", 200, "Freebox OS" , 1, { "sms"}, nil, nil}, ["OpenVPN"] = {"192.168.1.16", 443, "tcp", "", nil, "" , 1, { "email", "sms"}, nil, nil}, ["Redhat"] = {"192.168.1.17", 22, "tcp", nil, nil, "OpenSSH" , 1, { "email" }, nil, nil}, ["Google"] = {"www.google.fr", 80, "http", "/", 200, "Recherche Google" , 1, { "sms"}, nil, nil}} } local debug = false userID : liste séparée par des virgules des ID des utilisateurs qui doivent recevoir des notification par email (le mail est celui configuré pour chaque utilisateur dans le panneau de contrôle d'accès) smartphoneID : liste séparée par des virgules des ID des smartphones qui doivent recevoir des notifications push (à récupérer dans le toolkit de Krikroff ou via l'API : /api/iosDevices) sms : si vous avez une passerelle SMS sous Android avec SMS Gateway (ou équivalent) pilotée par un module virtuel, il faut renseigner ici les informations nécessaires. icons : si vous avez 2 icônes personnalisées, remplacer les valeurs nil par les ID numériques de vos icones (à trouver dans /api/icons) DEVICES : c'est la partie la plus longue à paramétrer, pour cela je vous ai laissé un exemple de tout ce que je monitore chez moi (j'ai juste changé les IP). C'est assez parlant, vous pouvez copier/coller en respectant bien la syntaxe. A noter que si l'avant-dernière colonne qui contient le nom facultatif d'une variable globale à incrémenter, celle-ci est automatiquement créée par le module. La dernière colonne permet d'annuler le monitoring d'un équipement particulier en fonction de la valeur d'une variable globale. debug : true ou false afin d'activer l'affichage étendu dans la fenêtre de débugage du bouton du module virtuel. Dans la Main Loop, le code est de Steven. Il y a une variable nbHeure permettant de paramétrer l'intervalle de vérification, par défaut à 1 heure. Si vous voulez un rafraichissement inférieur à 40 minutes, il suffit de tout remplacer par un simple fibaro:sleep(), car cette fonction ne plante pas pour les durées inférieures. Network_Monitor_v1.01.vfib Network_Monitor_v1.10.vfib Network_Monitor_v1.20.vfib

C'est une question récurrente, et la réponse est toujours la même : passe un maximum de gaines, même vide, partout : au sol (pour les prises), à 90cm (pour les interrupteurs), à 1,5m (pour les thermostats, tablettes tactiles), et en haut (pour les caméras, détecteurs de mouvement, ...) Ensuite tu seras libre t'enfiler l'aiguille et de rajouter le câblage désiré plus tard. Car même un module sans fil Z-Wave, peut avoir besoin d'un câble, par exemple pour amener une alimentation afin de remplacer les piles. Comme ton expression du besoin est encore trop vague, ça te laissera le temps d'y réfléchir en sachant que tout sera potentiellement réalisable. Car il n'y a rien de pire que de ne pas pouvoir réaliser un projet car on n'a pas de gaine qui passe à proximité. En parallèle de ça, et même si ce n'est pas directement lié à la domotique, passe un maximum de câbles réseaux RJ45 de bonne qualité (Cat 7 ou Grade 3S). N'hésite pas à en mettre plusieurs par pièce, genre 2/3 par chambre, et beaucoup dans le coin TV (TV, Box, Lecteur, HTPC, ampli, etc)

Dans les versions beta qui étaient très instables.