Lazer

oui vi faut être motivé, mais parfois pour une modif rapide ça va plus vite Je te conseille le PI 2, il est bien plus puissant, et a plus de RAM, et consomme moins. Que des avantages. Pour la SD, c'est tout à fait normal. La mémoire flash a par définition un nombre de cycle d'écriture limité. Dans les SSD, le phénomène est limité par des algorithme qui répartissent les écritures équitablement sur toutes les cellules de flash. Dans une carte SD, il n'y a pas ces algorithme, et bien souvent les puce de flash sont de faible qualité, à moins de taper dans les cartes haut de gamme (genre Sandisk Extreme Pro, voire carrément les carte à mémoire SLC (single bit per cell) comme en fabrique Panasonic, mais le prix s'envole.... largement plus cher que le Raspberry). Dans notre cas, comme on compte des impulsions à une fréquence élevée (en hiver, avec le chauffage électrique, les impulsions à chaque Wh s'enchainent très vite), alors on écrit beaucoup sur la carte SD, et toujours au même endroit (là où se trouve la base de données). Donc ce n'est pas viable. Ce problème de fiabilité de carte SD est très connu. Evidemment, dans les usages "normaux" des cartes SD (appareil photo, téléphone, autoradio, ...), comme on fait plus de lecture que d'écriture, le phénomène est moins visible. Mais il arrive quand même, surtout avec les cartes low-cost.

Ah oui les mirocontroleurs, mais là il faut toujours (je crois) un kit de développement spécifique. Là comme le RPI est un ordinateur, tu peux travailler comme tu veux dessus. Soit avec un écran/clavier/souris, mais c'est pas le but ici. Je me connecte dessus via le réseau, simplement en ouvrant une session SSH en ligne de commande, avec PuTTY. Pour l'éditeur, selon mon humeur j'utilise vi en ligne de commande, ou alors Notepad++ (sur mon PC Windows), qui est capable d'éditer des fichiers directement sur un serveur FTP (puisque le RPI est sous Linux, il intègre un serveur FTP, parmi d'autres choses). Bref, encore une fois c'est un ordinateur, donc les possibilités sont juste infinies, chacun a sa façon de travailler.

C'est du Linux sur processeur ARM, donc tu peux utiliser virtuellement n'importe quel langage existant. J'avais commencé mon projet en Python, car on trouve pas mal d'exemple de code sur cette plateforme, certainement car le Python est le langage le plus populaire sur Raspberry PI. Mais je rencontrais de gros problèmes de fuite mémoire menant au crash de Linux (swap plein....), et quelques problèmes liés au multithreading de mon appli. Comme je ne maitrise pas bien le Python, j'ai tout réécris en langage C, et compilé simplement avec gcc. Et ce qui est bien avec le C, c'est que c'est un langage qui ne pardonne pas les erreurs : on les voit immédiatement quand l'appli se crash, donc ça oblige à développer proprement. Depuis je n'ai plus aucun problème, c'est super stable, plusieurs mois de uptime sans souci Je ne suis pas développeur, mais j'ai quelques notions. Le plus gros souci à résoudre avec cette plateforme, c'est l'utilisation d'une carte (Micro)-SD, donc très peu fiable. Dans un projet comme celui-ci, on passe son temps à logguer des données, donc à écrire dans la base. Comme je le disais j'ai corrompu une carte en 3 mois, et maintenant je stocke les données en RAM, et je synchronise à intervalle régulier (24h). Tu trouveras de très nombreuses infos sur le Rapsberry PI sur Internet, tant cette plateforme est populaire. Il y a même quelques ouvrages papier en librairie (Amazon..... bouh je fais de la pub à un tueur de librairie )

Même si c'était exactement la même fréquence, il y a peu de risque de perturbations, car les trames ont une durée très courte. Donc les chances de collisions sont assez faibles, et même si ça arrivait, le Z-Wave est un protocole à retour d'état qui est capable de ré-emmètre les trames si nécessaires. J'ai chez moi plusieurs réseaux Z-Wave, et du EnOcean, et mon alarme, qui sont tous sur la même bande de fréquence. Aucun souci à signaler. A contrario, ce n'est pas comme pour le Wi-Fi, ou les transmetteurs TV sans fil à 2;4 GHz qui se perturbent mutuellement, car dans ce cas il s'agit de transmissions de données volumineuses, donc sans discontinuer. D'où les perturbations.

T'es toujours au taquet mprinfo Si c'est des FGS-221, donc l'ancien modèle, ça répond à la question de Nico : Amazon ne s'approvisionne toujours pas en direct chez Fibaro, mais par des circuits alternatifs. Ils ont dà» trouver un grossiste qui avait du stock.

Raspberry PI

Ca dépend comment c'est fait chez toi, mais perso sur l'arrivée générale c'est une grosse section. Bon faut dire aussi que ça part vers la maison, le garage, et l'extérieur. En 3/4", j'ai refait tout le circuit d'eau chaude à l'entrée et la sortie du ballon.

Mes voisins ont commencé àse poser des questions sur mon état mental quand ils m'ont vus assis àcoté du boitier ouvert du portail, avec un tournevis dans une main et le PC portable sur les genoux

C'est pour les sudistes ça Punaise, la pinte et les 2 limoncello de ce midi commencent à taper.....

Info complémentaire : ce serveur supporte 2 vitesses de RAM : 1333MHz et 1600MHz. Le processeur Celeron G1610T utilise la RAM à 1333MHz même si vous mettez des barrettes à 1600MHz. Comme je vise à terme un Xeon E3-1265L v2, il me permettra d'exploiter les barrettes à leur plein potentiel de 1600MHz.

Hey, ça a l'air pas mal du tout cette électrovanne ! Par contre en 3/4" c'est un peu limite pour l'arrivée générale, mais pour des réseaux secondaire ça peut le faire, surtout pour l'arrosage du jardin ! EDIT : d'après la doc, il existe un modèle plus gros en 1".

euh.... trop complexe pour moi.... enfin ça doit être faisable, mais j'ai pas 1 mois nuit et jour ày consacrer

@merick merci pour cette info. Bon ça se confirme, mon module doit avec un souci.... j'ai testé avec 3 piles neuves, avec différents chargeurs et différents câbles USB, et même USB+Piles simultanément, et lors de l'inclusion j'ai toujours un warning sur les batteries faibles..... je vois voir si ça peut passer en SAV. @Rem's je ne sais pas t'aider pour ta question de température.... peut-être une histoire de polling ? Sauf pour les paramètres, dans les dernières v4 le template est complet, donc tu peux faire une reconfiguration du module, voire carrément exclure/inclure, tous les paramètres devraient apparaitre.

Ca dépend (ça dépasse... copyright la troupe du Splendid). Les modules à piles près de la box. Les modules sur secteur, si ils ne sont pas trop loin de la box je tente une inclusion direct à sa place définitive, sinon j'utilise une prise avec 2 fils et un domino pour l'inclure à proximité, puis le déplacer à sa position définitive.

Je viens de vérifier sur leur site, ce qui confirmer et complète ce que je disais initialement : Leur gamme de routeurs EdgeMax utilise un POE propriétaire, qui permet d'alimenter leurs points d'accès Wi-Fi Unify AP. Leur gamme de switchs Unify utilise bien du vrai POE 802.3af qui pourra donc alimenter n'importe quel équipement à ce standard. Je rappelle que les routeurs EdgeMax n'ont un intérêt que si tu souhaites remplacer la box fournie par ton opérateur ADSL/Fibre. Leurs points d'accès Wifi sont absolument excellents, et n'ont pas d'équivalent dans cette gamme de prix. Leur force est de pouvoir fonctionner ensemble, pour former un grand réseau dans la maison/jardin/whatever... comme en entreprise quoi. Chaque point d'accès est fourni avec un injecteur POE propriétaire, donc ils peuvent fonctionner avec n'importe quel switch standard du marché. En ce qui concerne les switchs, je n'ai pas vu beaucoup de retours sur la gamme Ubiquiti, pour une raison simple : à ce niveau de tarif, c'est pas vraiment intéressant pour des particuliers.

RAM Compatible HP MicroServer Gen8 : 16 Go ECC Unbuffered DDR3-1600MHz PC3-12800 2 barrettes de Kingston KTH-PL316E/8G Installation de ESXi 5.5 en cours sur une carte MicroSD de 16 Go que j'ai retrouvé dans mon stock. Installation grâce au montage de l'ISO via le réseau depuis l'interface de management ILO.... pratique, même pas besoin de lecteur DVD ou clé USB

Disque interne = 2 Go de mémoire SLC Disque externe = clé USB Recovery = 4 ou 8 Go (selon la génération de HC2) de mémoire MLC ou TLC, donc peu fiable, dont seulement 4 Go sont utilisés (cf topic HC2 USB Recovery Tweaks) je doute fort qu'ils prennent le risque de mettre une partie du système sur la clé externe recovery.

La clé interne fait 2 Go, soit réellement 1910 Mo / : 954 Mo swap : 244 Mo /var : 668 Mo => Total : 1866 Mo Bref, seulement 44 Mo de libre sur la clé.... je doute vraiment qu'ils osent toucher à la structure de la table de partition pour seulement 44 Mo, A mon avis ils ont juste fait du ménage qq part

ça m'a aussi interpellé cette phrase Berale, j'avoue que je ne sais pas quoi en penser....

Cool, grâce à vous 2 ils ont trouvé un bug et ils vont le corriger Attendez la prochaine mise à jour qui intègrera le correctif je pense.

Moi aussi j'aimerais bien ne pas aimer mon propre message, mais bon..... malheureusement faut faire avec, car c'est typiquement le genre de fonction qui n'arrivera jamais sur HC2.

LUA : os.execute() Mais c'est bloqué par Fibaro pour des raisons de sécurité. On a une implémentation de LUA très limitée sur HC2.

@Shyrka973, non pas besoin de template, les release v4 récentes de Fibaro ont bien le template pour le ZXT120. Par contre si je te comprends bien, pour les 2 derniers modules en v1.12, tu en as un qui n'a pas de souci de batterie, et un autre qui a le "bug" ? @merick, merci, donc mon module a peu être vraiment un problème.... c'est quelle version du module que tu as (visible dans son panneau de propriétés) ?

moi j'éviterais de rebooter au milieu de la conversion...... ça risque de finir en recovery Essayez de bouger le support pour qu'ils se connectent et regardent en live ce qui se passe.

Quand je vois les scripts de migration depuis la 4.05x, ils font beaucoup plus de vérifications, et de corrections d’anomalies dans la DB. Clairement ils se sont attaqués sérieusement aux instabilités des premières v4. Je suis encore en 4.049 mais je pense que je vais pas tarder àmigrer, ça me parait beaucoup moins risqué maintenant.