Lazer

Normalement, il a reçu un email suite àton MP. Attends un peu, il est peut-être occupé/absent/...

Les disques durs, tu les mappes en RDM à la VM Xpenology. Donc DSM voit autant de disques que tu lui a présenté, et tu peux donc étendre le RAID sur les nouveaux disques que tu ajoutes, il n'y a aucun souci J'ai cru à un moment que tu voulais créer des disques virtuels (depuis le datastore) et les présenter à la VM Xpenology. A ce moment là DSM aurait vu des disques physiques (RDM) et des disques virtuels (datastore) aux caractéristiques et performances très différentes, ce qui n'est pas conseillé.

Je ne suis pas certain de bien comprendre ce que tu dis, mais àpriori oui c'est possible. Par contre tu auras de très mauvaises performances, parce que mélanger du physique et du virtuel, c'est pas top quand même. A réserver aux tests, mais pas àla prod.

2 - Non c'est hardware, entre le chipset et le processeur. Aucune chance d'arriver à"créer" les fonctions VT-D avec un BIOS moddé. 3 - Encore une fois, DSM n'est pas sur le SSD, il est installé sur le ou les disques durs de 2 To (ou plus). Sur le SSD (=datastore), il y a uniquement le nanoboot de 32 Mo qui permet de démarrer la VM Xpenology et de faire croire àDSM que nous sommes sur un vrai Synology. C'est làque ce trouve le hack de ce projet Xpenology. Le SSD est effectivement beaucoup plus fiable qu'un disque dur. Au pire, si le SSD crame, tu remets un autre nanoboot et tu redémarres ta VM Xpenology sans souci puisque tout est sur les disques durs (je me répète...) 4 - Euh non, les VLANs ça ne sert que pour la sécurité. En terme de performances, ça n'apporte rien. Par contre si tu as besoin de perfs importante entre les différentes VM (sans sortir du serveur), il peut être intéressant de créer un vswitch dédié avec une interface réseau virtuelle supplémentaire sur chaque VM. Mais encore une fois, pour l'accès extérieur, les VLAN ne peuvent pas améliorer les performances (et même les réduire, puisqu'un VLAN ce sont quelques octets rajoutés en début de trame IP).

bouhhhh désolé pour ce post pas vraiment constructif, mais j'ai pas vraiment d'idée.... j'espère que tu trouveras une solution autre que le renvoi en garantie. Tu as essayé de la laisser refroidir ?

32 Mo (Mega-octets) : seul le nanoboot va sur le datastore/SSD. Les données et applications sont sur le disque dur de 2 To. Si tu prends un SSD de 64 Go, ce sera quasiment entièrement disponible pour les VM Windows et Linux. Non, impossible avec ESXi sur ce serveur Le RAID de ce serveur est du pseudo-RAID matériel, qui n'est pas reconnu par ESXi. De plus, ESXi ne permet pas de faire du RAID. Donc si tu veux du RAID, tu n'as pas d'autre choix que d'acheter une carte RAID PCI reconnue par ESXi (voir la liste de compatibilité sur le site de VMware) Si tu as plusieurs disques durs de 2 To, tu peux les mettre en RAID SHR sous DSM, mais cela protégera les données + applis de DSM, mais pas le datastore sur SSD. SCSI Paravirtual conseillé pour les performances, mais ce n'est pas supporté sur les vieux OS, donc parfois il faut repasser en LSI SAS Logic (par exemple avec Windows XP, etc...). Si tu installes les VMtools, ce qui est conseillé, cela apporte les drivers permettant de passer en SCSI Paravirtual. Par contre, si tu parles du réseau, alors c'est VMXNET3 qui est conseillé, et la même remarque que précédemment s'applique.

[Tuto VidéoSurveillance] Piloter L'enregistrement Des Caméras Avec Synology Surveillance Station

je suis bien illuminé par le spot au dessus de ma tête, mais àpart ça, ça ne m'arrive pas souvent.... même jamais

Pour Oufman, appelles-le par MP et dis lui de venir par ici, pas certain qu'il voit passer ton message autrement En attendant regarde le travail de ce gars là : https://plus.google.com/u/0/+OlivierCarreno/posts

Les trous sont tout petits, il faut des fils comme on utilise en électronique sur les plaques d'essais, ou àdéfaut 2 fils d'un câble réseau doivent faire l'affaire. C'est un interrupteur utilisé en contact sec, il n'y a aucune puissance, donc inutile d'utiliser des fils 1,5 ou 2,5mm² habituels en électricité. N'importe quel bouton fera l'affaire, pourvu qu'il est connecté en contact sec sur ces 2 fils qui sortent du module, et surtout pas sur le 230V.

question subsidiaire : peut-on désactiver le module via un script LUA ou l'API ? Ce qui permettrai d'intégrer ça dans des scénarios, parce qu'expliquer àla famille qu'il faut aller dans l'interface d'admin de la HC2 pour désactiver l'allumage automatique, c'est pas très WAF/HAF :/

c'est bien pour ça que j'attends que la v4 soit sortie pour mettre àjour une bonne fois pour toute mes scripts. Si j'avais une seconde HC2, et le temps de jouer avec, je pourrais préparer tout ça, mais pour le moment je garde ce qui fonctionne bien comme ça. On peut quand même se dire que la v4 partira sur de bonnes nouvelles bases, ce qui plus évolutif pour l'avenir. Surtout si le nouveau moteur Z-Wave est plus stable (moins de nœuds morts, etc...) Làavec le GetType, les nouveaux noms ne sont pas déconnants, mais c'est quand même pas très sérieux de tout changer comme ça en cours de route. Et je ne te parle pas de l'API HTTP, c'est encore pire !!!

Hum, je me demande si Krikroff n'avait pas dit que la fonctionne Net.Fhttp() était en cours d'abandon pour être remplacer par autre chose....

Bon, ça progresse, il envoie bien les données au NAS, mais les pages Web sortent une erreur.... pas cool il doit y avoir un problème quelque part avec les scripts PHP, mais je ne vois pas où, vu que ça fonctionne pour la météo

Ah ouais quand même, ils ont tout changé, mais c'est pas possible de bosser comme ça !! Plus aucune rétro-compatibilité. Ca promet pour la mise àjour de tous les scripts qu'on a sur nos box.... je sens que la migration en v4 va être compliquée, ça promet un long week-end.... En attendant, je te propose de modifier le code du bouton n°1 comme suit, et normalement les graphs de temp/humidité/thermostat/luminosité devraient fonctionner : local updatechart = Net.FHttp("1.2.3.4") local i = 0 local maxNodeID = 150 local deviceType2 = "" for i = 0, maxNodeID do local deviceType = fibaro:getType(i) --fibaro:debug("i = "..i.." / deviceType : "..deviceType) if deviceType == "com.fibaro.temperatureSensor" then -- old : temperature_sensor deviceType2 = "temperature" elseif deviceType == "com.fibaro.humiditySensor" then -- old : humidity_sensor deviceType2 = "humidity" elseif deviceType == "com.fibaro.thermostatSetpoint" then -- celui-làil faudra vérifier son nouveau nom, ceci n'est qu'une supposition... àsuivre deviceType2 = "temperature" elseif deviceType == "com.fibaro.lightSensor" then -- old : light_sensor deviceType2 = "light" end if deviceType2 ~= "" then --fibaro:debug("found deviceType2 : "..deviceType2) payload = "/graph/data_post_" .. deviceType2 .. ".php?id=" .. i .. "&value=" .. fibaro:getValue(i, "value") fibaro:debug("payload : "..payload) response, status, errorCode = updatechart:GET(payload) fibaro:debug("status : "..status.." errorCode : "..errorCode.." response : "..response) deviceType2 = "" end end payload = "/graph/data_post_temperature.php?id=3&value=" .. fibaro:getValue(3, "Temperature") --fibaro:debug(payload) response, status, errorCode = updatechart:GET(payload) payload = "/graph/data_post_humidity.php?id=3&value=" .. fibaro:getValue(3, "Humidity") --fibaro:debug(payload) response, status, errorCode = updatechart:GET(payload) fibaro:log("Environmental uploaded") Envoie nous aussi le résultat du Debug STP, afin que je vérifie que tout fonctionne bien. Normalement tu devrais avoir les courbes de température qui fonctionnent.

Je verrais bien un truc comme ça : local updatechart = Net.FHttp("1.2.3.4") local i = 0 local maxNodeID = 150 local deviceType2 = "" for i = 0, maxNodeID do local deviceType = fibaro:getType(i) fibaro:debug("i = "..i.." / deviceType : "..deviceType) if deviceType == "temperature_sensor" then deviceType2 = "temperature" elseif deviceType == "humidity_sensor" then deviceType2 = "humidity" elseif deviceType == "thermostat_setpoint" then deviceType2 = "temperature" elseif deviceType == "light_sensor" then deviceType2 = "light" end if deviceType2 ~= "" then fibaro:debug("found deviceType2 : "..deviceType2) payload = "/graph/data_post_" .. deviceType2 .. ".php?id=" .. i .. "&value=" .. fibaro:getValue(i, "value") fibaro:debug("payload : "..payload) response, status, errorCode = updatechart:GET(payload) fibaro:debug("status : "..status.." errorCode : "..errorCode.." response : "..response) deviceType2 = "" end end payload = "/graph/data_post_temperature.php?id=3&value=" .. fibaro:getValue(3, "Temperature") --fibaro:debug(payload) response, status, errorCode = updatechart:GET(payload) payload = "/graph/data_post_humidity.php?id=3&value=" .. fibaro:getValue(3, "Humidity") --fibaro:debug(payload) response, status, errorCode = updatechart:GET(payload) fibaro:log("Environmental uploaded") A mon avis c'est la fonction fibaro:getType() qui échoue. Ensuite tu ouvres la fenêtre de debug, tu appuies sur le bouton 1, et du copie/colle le résultat ici.

Si tu parles bien de ces icones là , alors je dirais que c'est tout à fait dans l'esprit Fibaro : J'imagine que tu joues aussi avec les calques sous Photoshop, et à ce moment là nos icônes sont plus simples, puisqu'il suffit d'enlever le cadre, le fond, et le texte par rapport à tes icônes sur eedomus.

Surtout pas, c'est pire avec les Beta !! Les FGMS ne fonctionnent plus du tout, @Nico a fait un recovery àcause de ça justement. Reste en stable, et attend sagement la v4 stable.

Il y a quelques mois, il n'y avait encore aucune rumeur sur cette passerelle I/O HomeControl. Et en plus, cela oblige à utiliser le module officiel Velux KUX 100, qui est cher, et consomme plein de watts pour rien en veille. Donc la future passerelle, ce sera bien pour domotiser une installation existante (filaire ou solaire), mais dans une nouvelle installation la question de la meilleure solution technique restera ouverte.

Des "plaques de plâtres de 5 cm d'épaisseur" sous pente ??? C'est à dire des carreaux de plâtres ? Ce n'est pas très courant ! Moi j'avais un simple placo : - j'ai enlevé quelques tuiles - soulevé l'isolant - percé un petit trou de diamètres 6 ou 8 mm - passé le câble dans le trou - positionné toutes l'électronique à l'intérieur, dans une boite au fond d'un placard. Comme me l'avais fait remarqué Benjy, heureusement que je n'avais pas de film étanche sous-toiture, sinon ça aurait été plus complexe de gérer l'étanchéité. Dans ton cas, si les plaques des platre sont plus épaisses, ça ne change pas grand chose, un trou c'est facile à faire avec n'importe quel forêt. Si l’électronique crame, c'est quand même plus simple de tout avoir à portée de main, que sous les tuiles ou au milieu de l'isolant. Et pour le respect de la norme NFC15-100 pareil.

@Cédric : valeur de 44% lorsque le module maitre est détecté en sonde d'humidité. Lorsque j'avais joué avec, il était parfois détecté en mode sonde de température, avec une valeur différente. En fait, cette valeur ne veut rien dire, et le fait que le module maitre soit détecté en humidité ou température est un bug du HC2 depuis plusieurs versions. Normalement, le module maitre devrait être reconnu comme un multi_level_sensor, et les modules enfants doivent bien être chacun un temperature_sensor et humidity_sensor. Les utilisateurs qui ont enregistré leurs ST814 dans la HC2 avec les vieux firmwares n'ont pas ce problème. Ca sera surement corrigé en v4 @Krikroff : oui les sondes Oregon ont très bonne réputation sur la fiabilité, et le choix est large, avec certains modèles qui ont un afficheur. Mais ça oblige à avoir encore une autre passerelle en 433MHz, et ce protocole n'est pas routé, donc il ne bénéficie pas d'une grande portée comme le Z-Wave et le EnOcean avec leurs réseaux maillés. Cela peut-être un problème pour les grandes maisons et/ou avec du béton partout.

Sous les tuiles, quand il fait 30°C dehors, ça chauffe facilement à 40°C durant toute l'après-midi avec le soleil qui cogne dessus. Je n'ai pas de retour sur la fiabilité de l'électronique à cette température là , espérons que ça passera. Entre les 2 couches d'isolant ça devrait limiter les effets. Pour manÅ“uvrer le volet en manuel, je ne vois pas d'autre option que mettre des interrupteurs sur les entrées du module FGRM.

Oui je disais 15%, mais en fait sur mes 3 ST814, j'en ai 2 qui sont plus proches des 20% d'humidité de différence. Quant à la Netatmo, j'avais vu je ne sais plus où quelqu'un qui se plaignait beaucoup de la faible qualité des capteurs employés. Pour le bruit et le C02 je n'ai pas d’éléments de comparaison, mais l'humidité est dans les choux comme comme les ST814. La température me semble précise par contre Sinon, un petit comparatif au sujet des températures uniquement : Comparatif des sondes de température utilisées en Domotique

La Netatmo n'est pas beaucoup plus fiable apparemment. La mienne a presque le même décalage que le ST814 pour l'humidité. Les sondes EnOcean Tryo2Sys sont beaucoup plus fiables, mais plus cher, sans affichage, et protocole différent obligeant àpasser par une passerelle.

Attention àla température sous les tuiles en été.