Lazer

quoi ? Je ne comprends pas ce que tu veux faire avec ta scène , des triggers ?? Perso j'ai juste un VD qui envoie des ordres au module... j'avais donné toutes les commandes en LUA il y a quelques pages (identifiées grâce au mode bloc, pour une fois que c'était utile ce mode bloc ... ) C'est tout, pas besoin de plus. Après que les commandes soient dans une scène ou un VD, ça ne doit rien changer. Juste un truc qui n'a jamais fonctionné avec ce module : c'est la sonde de température. Il faut "poller" manuellement le module pour récupérer la valeur, car celui-ci ne l'envoie pas automatiquement. Et quand bien même, comme la précision est de 1°C, c'est totalement inexploitable dans un scénario. J'utilise donc un autre capteur de température dans la pièce (le bon vieux ST814, toujours aussi efficace)

@sebcbien, ta théorie, tu peux nous la traduire en LUA, ça sera plus compréhensible là @domomat bon moi je n'y connais rien à la loi, mais si j'interprète les conditions d'utilisation de Jeedom, on n'a donc pas le droit d'obtenir les sources des plugins payant sans l'acheter avant. Merci cela répond donc à ma question

Le souci de CentOS, c'est que ce n'est pas Redhat. C'est con mais c'est comme ça. Par exemple, il y a des éditeurs d'applications qui certifient leur application sur Redhat, mais pas sur CentOS. En clair : ton logiciel bug, tu appelles le support de ton éditeur, il t'envoie balader parce que tu n'as pas acheté la distrib Redhat officielle. et le terme "Red Hat Enterprise Linux customers" fait toute la différence.... bon après c'est leur business, je comprend parfaitement Mais ça a bien changé, j'ai commencé Redhat dans les années 90, c'était réellement gratuit. EDIT : désolé pour le HS total sur ton topic....

@sebcbien je sais bien pour Redhat, mais ces malins là , en plus de vendre du support, ont rendu la distribution Redhat inaccessible au téléchargement. Donc si tu ne payes pas, tu ne peux plus avoir Redhat. Il y a les solutions de contournement CentOS, mais ce n'est pas strictement la même distribution. @i-magin : ah je t'ai posé une colle

Les plugins sont tous open-source ? Si oui, alors pourquoi seraient-ils payant ? Il suffit donc de prendre le source, de le compiler, et de l'installer manuellement sur Jeedom, tout cela gratuitement, avec juste un peu d'huile de coude ? Est-ce possible ?

Ne soit pas si pressé, il leur faut au moins 1 mois de travail acharné pour livrer une nouvelle beta

Oui Jojo je suis bien d'accord avec toi C'est le service rendu aux utilisateurs qui prime. Mais souvent, la plupart des applicatifs sont arrêtés même un court instant, par exemple une fois par nuit pour les backups. Même si l'application n'est pas totalement arrêtée, elle est suspendue (Exemple un serveur Oracle en mode Begin Backup). Ce que je veux dire, c'est qu'il y a tellement de comportement différent d'une application à une autre, qu'il est difficile de trouver une mesure commune. Alors on peut parler de taux de disponibilité de l'application. Mais le uptime reste une information purement système. Un système qui reboote, sur des très gros serveurs, c'est pas loin de 1 heure ! Dans ce cas là , tu imagines que l'indisponibilité de l'application est colossale (le temps qu'elle même redémarre). Mon watchdog avait pour but de redémarrer les applications au plus vite (donc sans rebooter, même si la HC2 reboote très vite), afin que le service domotique soit toujours rendu. Que cela se passe la nuit ou le jour, au final ce qui compte c'est que je n'ai plus été indisposé par les 503 depuis que j'ai ce watchdog système. Même principe que le watchdog des Scènes+VD.

@jojo bon si on ne compte pas tous de la même façon, ça va pas aider Un uptime c'est le temps depuis lequel un serveur tourne, même si l'application est redémarrée. C'est quand même très con de la part de Fibaro de mettre leur pseudo uptime différent dans l'API. Enfin on n'est plus à une abberration près.... perso cela m'embête, car je comptais utiliser cette variable pour détecter si la box vient de booter ou seulement si les services ont redémarré, grâce à une scène au autostart. Bien sur cela n'est pas réalisable, ce "uptime" là repars systématiquement à 0, donc il est inutile.

@i-magin, oui j'avais bien constaté en l'installant que son auteur est slobberbone. Je ne savais pas que le plugin n'est plus compatible.... ce n'est pas vraiment indiqué sur la fiche du market. Ceci dit je comprends parfaitement qu'il ne puisse pas trop le corriger dans l'immédiat. Le souci des apps qui ne deviennent plus compatible avec le temps n'est pas nouveau, c'est tout aussi vrai pour les apps sous Windows, sur Android, iPhone, etc. A partir du moment où tu veux faire un système ouvert, ce "défaut" est inévitable. C'est au market de spécifier clairement si le plugin est compatible ou non, les commentaires des utilisateurs pouvant aider. Ensuite, si le développeur a le courage de faire vivre son appli, tant mieux, sinon il tombera aux oubliettes et sera remplacé par un autre plugin équivalent (ou mieux) créé par un autre développeur. C'est comme ça l'informatique.

Il est totalement dépassé ce routeur RT1900AC, vous arrivez encore à naviguer sur Internet avec ce vieux bousin ? Computex - Synology persiste dans le routeur haut de gamme avec le RT2600AC

C'est juste un /etc/init.d/fibaro-start restart donc Linux n'est pas rebooté, cela n'impacte pas l'uptime Par contre, j'ai constaté que le "faux" uptime remonté par l'API de la HC2 ne compte que l'uptime de l'application, pas celui de l'OS.

Avec mon test, je suis bien repassé en 4.080, puis ensuite j'ai remis à jour en 4.082 sans souci. Si tu veux être certain, le seul moyen c'est le recovery, mais tu vas perdre tes icones...

Tu as vu ceci ? http://www.domotique-fibaro.fr/index.php/topic/2513-google-calendar-vers-hc2hcl/

ça doit certainement être totalement propriétaire.....

Aucun problème sur ma box de test, je suis passé de 4.082 à4.080. Mais j'ai une petite base de données, très peu de modules sur cette box.

La box est fiable, c'est le logiciel Fibaro qui n'est pas fiable. Cette clé recovery ne sert qu'à la protection du logiciel de Fibaro, donc pour moi cette clé fait partie du logiciel et non du matériel. Mais sinon on est bien d'accord, cette utilisation de la clé recovery est totalement aberrante...

Je lance le startUpgrade sur ma box de test et je te dis... Bon sinon 503 cette nuit sur ma box de prod Services redémarrés automatiquement, je reste dans le concours de l'uptime : 13 days, 12:46

oui je suis bien d'accord. Pour le moment Jeedom en test va bien dans une VM, mais si je devais le mettre en prod et devenir le point central de la domotique à la maison, je le mettrai dans une boite dédiée. Le NUC est une bonne solution, mais j'attends de voir ce que donnera la Jeedom Center. En tout cas j'adore la HC2 en tant que box, elle est sur une base matérielle et OS ultra stable (CPU Intel sous Linux, rien de tel pour la fiabilité, c'est à des années lumières d'un raspberry PI et d'une carte micro-SD)

oui un HP Proliant MicroServer Gen8 dont j'ai changé le CPU, upgradé la RAM à 16 Go, installé un SSD et des disques durs, et qui tourne sous ESXi. Un vrai petit serveur

:lol:

Mon Xeon fait 29W (sans compter les disques durs). C'est très raisonnable. Mais surtout j'ai pas loin d'une 10zaine de VM qui tournent dessus, la principale étant mon NAS (Xpenology), mais aussi FHEM pour toute la gestion EnOcean. Donc ça fait plein de choses, la consommation est très maitrisée car c'est un Xeon Low voltage. Ceci dit c'est vrai que les NUC c'est excellent pour plein d'usages Aller tient un défaut à Jeedom que j'ai trouvé ce soir : pour installer le plugin SNMP, il faut ouvrir un Shell et installer le paquet snmp à la main avec la commande qui va bien (apt-get ...). Rien de méchant, mais pour le coup ça fait barbu, et pas encore totalement grand public. Mais je chipote, Jeedom a énormément progressé en 2 ans

@Jayce74, mouais, il rame pas trop ton Jeedom sur ton système ? Là ça pootre : Déjà l'uptime supérieur à la HC2, c'est cool Bon faut dire que l'update du Core Jeedom sans rebooter Linux, déjà ça change la donne

Pfff, on sait tous que tu dors avec ta wifedomus

Notre foie ne s'en porterait que mieux

Je vais laisser les experts de GEA te répondre Mais il faudrait que tu prennes au moins la température en compte, qui est le principal paramètre faisant varier le taux d'humidité relative. Par contre pour étalonner tout ça, il faudrait que tu observes les courbes de variation d'humidité intérieure en fonction de la température+humidité extérieures, et du fonctionnement de ta VMC. Pour cela, les graphs de Domocharts peuvent t'aider. Mais ça va pas forcément être simple à régler tout ça. Ca va te faire plusieurs règles GEA.