Lazer

Euh, ça doit fonctionner sur HC Lite uniquement alors. Parce que je n'ai jamais vu de lien "Recovery from File" sur l'écran de recovery de la HC2 :

c'est plus compliqué, il ne faut pas se contenter du ping, mais faire un "curl" pour récupérer la page web de la HC2. En fonction du retour, on détecte si il y a eu un 503, auquel cas on appelle la page sus-mentionnée (encore avec la commande curl) Bon c'est sur que si tu ne sais pas écrire en Shell ça ne t'avance pas beaucoup.... Et puis tu as déjà un watchdog qui tourne en root sur la HC2 qui fait le job. Ca serait surtout utile aux autres. Si quelqu'un sait écrire un script Shell et a un peu de temps, ça serait une idée sympa.

Dgk en effet si tu as déjàla Diagral alors tu pourrais utiliser leurs détecteurs extérieurs. Avec un FGK 101 dedans comme j'ai expliqué, tu as le meilleur des 2 mondes : - Pré alarme faible sur la sirène. - Remonté d'information dans la domotique pour piloter caméras, éclairages, sirène Z-Wave, etc

Il existe déjà2 ou 3 fils de discussions sur le forum, avec des infos assez techniques et poussées sur les alarmes. Faut juste retomber dessus. Le souci des alarmes pro, c'est qu'elles ne sont pas vendues en direct au grand public, sauf àtomber sur les bonnes boutiques en ligne (et eBay) qui les vendent quand même en direct. Et c'est un milieu très fermé, difficile d'obtenir de l'information. Mais il est certain que si je devais refaire une nouvelle installation, je prendrais une alarme pro. Parce que les alarmes grand public, c'est cher et limité en possibilités de domotisation. Cf mon tuto Diagral....

Moi ce que j'en dis, c'est l'occasion d'installer une vraie alarme, pas un truc bricolé en Z-Wave qui ne sera jamais aussi fiable. Pense aussi àla simulation de présence : allumage des lumières le soir pendant votre absence.

La page qui apparaît lors d'une erreur 503, avec la possibilité de redémarrer les services, ne fait pas la même chose que ce lien là. Ce lien làest fiable àtous les coups, d'où l'idée d'en faire un watchdog.

En effet la surveillance de la RAM ce n'est plus vraiment utile depuis la 4.082. En fait, j'ai commencé à créer de nouvelles pages de génération des graphiques afin d'empiler proprement les 4 courbes de la RAM sur un beau graph. A terme, cela permettra de générer des graphs personnalisés de n'importe quelles autres données. Mais j'ai stoppé en plein milieu de mes devs en décembre dernier, et la suite ça ne sera pas pour tout de suite.... Pour tes pellets, c'est quoi ton unité ?

Mouais, ça fait pas 23cm tout ça

4.082, on est sur le bon topic mince, je viens de me rendre compte que ma signature n'est pas à jour..... je vais corriger cela

Du coup je ne suis content de ne pas avoir upgradé la RAM, ce n'est plus utile 1 Go rulez

cela ne m’impressionne pas

up 7 days, 16:08 et Used RAM bloqué à23%, c'est magnifique

@Jojo, dans ton outil de surveillance que tu avais fait depuis ton Syno, il pourrait être intéressant d'ajouter l'appel àcette URL dans ton script. Cela permettrait d'avoir un watchdog externe, que tout le monde pourrait faire tourner sur son Syno, sans avoir besoin de rooter la box.

je préfère ne pas intervenir

Moi FGK 101 dans mes détecteurs extérieurs, voir tuto Diagral.

Vous voulez savoir pourquoi cette page fonctionne à tous les coups ? Facile, elle exécute ceci : sudo /etc/init.d/fibaro-start restart Ca ne vous rappelle rien ?

Encore une box domotique pour ceux qui croient encore au père noel. Ce que je veux dire, c'est que ça ne serait pas le premier projet communautaire qui promet monts et merveilles sans qu'on ne voit jamais rien venir.

Jayce74 clairement, on est des pionniers, des défricheurs. Comme ceux qui faisaient de l'informatique dans les années 80. Il a fallu attendre 20 ans pour que Mme Michu achète un ordinateur à pas cher qui fonctionne bien du premier coup (euh.... c'est faux ce que je dis, les netbook à pas cher des années 2000 c'était de la vraie m....) Alors certes tout va plus vite aujourd'hui dans les nouvelles technos, donc il faudra peut être attendre moins de 20 ans avant que ça ne se démocratise, mais il est certain que le marché va être bouleversé par rapport à ce que l'on connait.

@jerome_clamart Pour mon escalier j'ai ces valeurs qui concernent la luminosité, qui donnent entière satisfaction. A noter que je n'utilise pas l'association direct avec la lumière, mais c'est GEA qui gère allumage + extinction auto avec d'autres conditions : Paramètre => Valeur 8 => 0 9 => 200 lux => en fait on s'en moque, puisque le paramètre 8 est toujours actif. 40 => 50 lux 42 => 3600s => celui là vous pouvez le baisser fortement si vous voulez forcer une remonté plus fréquente afin d'affiner vos scénarios.... attention quand même à la consommation de piles => En journée ça ne changera pas grand chose (car c'est le paramètre 40 réglé à 50 lux qui fera la différence) mais le soir, lorsque la luminosité de la pièce est en mode tamisée autour de 50 Lux, le paramètre 40 devient totalement inactif => Donc l'intervalle d'envoi des données prend tout son sens.

Il semble (sans chiffres officiel à donner) que les ventes de box Fibaro ont très fortement chuté, en tout cas en France. Je suis persuadé que notre forum a fortement bénéficié à Fibaro qui a vendu beaucoup de box grâce à l'aide et les tutos qu'on y trouve. Et je pense aussi que les plaintes d'utilisateurs leur nuisent. Je n'ai aucun problème avec ça, c'est à Fibaro d'y remédier. Ne t'inquiète pas pour leur santé financière, ils font leur marge sur les quantités astronomiques de modules Z-Wave. Je m'inquièterais plutôt pour Connected Objects, qui risque de ne plus vendre beaucoup de box avec la concurrence de Jeedom. Ca pourrait bien finir comme Zodianet.

Une fois bien paramétré, ce capteur est absolument parfait pour la mesure de luminosité J'ai de superbes courbes de luminosité dans Domocharts qui révèlent bien les variations tout au long de la journée. Mais encore une fois, les valeurs par défaut ne sont pas bien choisies, et il faut lire la doc pour bien le configurer. A la limite, si on voulait être tatillon, ce n'est pas un capteur de luminosité qu'il faudrait pour l'extérieur, mais un capteur d'UV. Car là on aurait une mesure qui permette en plus d'agir sur les volets pour la gestion thermique du bâtiment. ce que ne permet bien sur pas un FGMS. Sinon il me semble que @mprinfo a aussi un FGMS dehors, sous abri. Je pense qu'il fonctionne toujours.

Gros +1 C'est là qu'on voit la valeur ajoutée d'un informaticien de métier. Enfin surtout d'un développeur. Je ne suis pas développeur, mais j'en ai fait sufisament pour avoir les bases (et aussi savoir que je ne voulais pas en faire mon métier). Mais moi je fais de l'admin système+stockage, et je vois bien les systèmes qui fonctionnent mal, à cause des applications mal codées (même sur des serveurs à > 100k€ unitaire) Pour une fois que la déformation professionnelle est utile.... C'est un peu triste, mais aujourd'hui la domotique c'est une très grosse majorité d'informatique, et un tout petit peu d'électricité. C'est le chalenge des constructeurs de proposer une offre domotique permettant de masquer totalement l'aspect informatique. Comme Apple a sur le faire avec ses iPhone. (vous savez que je n'aime pas leurs produits, mais ils ont apporté beaucoup pour le grand public non-informaticien). En tout cas Fibaro en est très très très très loin, malgré un marketing d'enfer.

En réalité, nos VD ne fonctionnaient pas très bien.... les 503 ne sont pas nouveaux et datent des toutes premières v4. Sauf que la nouveauté introduite dans cette nouvelle version (suppression du process Router, et simplification de l'architecture) apporte du bon (meilleures performances, fin des fuites mémoires), mais a des effets de bord.... le principal étant d'amplifier encore plus qu'avant les 503. Mais je le répète, ce n'est pas nouveau. Maintenant on est quasiment certain de l'origine (ou devrais dire d'une des origines possibles, jusqu'à ce que Fibaro la corrige et qu'on en découvre d'autres.... ) sont des races conditions, c'est à dire 2 process qui viennent modifier simultanément la même donnée. Et à lire les retours d'expériences des uns et des autres, cela confirme de plus en plus ce que je pensais et avait déjà déclaré sur le forum : la qualité de notre code a une importance considérable sur notre box. Et à celui qui va me dire que c'est pas normal que notre box soit si "fragile" et ne sache pas traiter les cas d'erreurs, je suis bien d'accord, et le premier à le dire depuis longtemps sur ce forum. Les devs de Fibaro sont des gros nuls, c'est un fait Mais il faut faire avec, et adapter son code pour limiter les plantages, donc à nous de coder le plus proprement possible. Cette remarque serait valable pour n'importe quel développement, et l'histoire de l'informatique montre bien que la qualité d'un code fait la stabilité d'une machine toute entière (souvenez vous les vieilles versions de Windows, qui plantaient lamentablement quand un seul programme bugguait. Heureusement cette période est révolue, mais elle a durée très longtemps (jusqu'à l'apparition des noyaux NT pour les connaisseurs, que l'on a retrouvé sur les versions grand public à partir de Windows 2000). Idem avec les premières versions d'Android d'ailleurs. Ou alors on va voir ailleurs => de plus en plus de monde visiblement, vous avez surement raison Quand je vois Sebcbien qui a passé un temps fou également sur HC2, et qui passe maintenant (avec succès) sur Jeedom, j'admire sa motivation Seb je suis globalement d'accord avec tout ce que tu dis. J'ai choisi la HC2 car à l'époque c'était la seule qui vendait du rêve (et surtout l'absence de cloud), mais la réalité est tout autre, comme tu le dis le produit n'est pas fini, et totalement inaccessible au grand public (mais ce dernier adjectif est valable pour la domotique tout entière, car ce n'est pas Jeedom ni Lifedomus ni <insérer ici votre box préférée> qui changent la donne) Ce n'est pas la première fois que je dis que si je devais refaire une install domotique je partirais sur autre chose aujourd'hui. Sinon oui je fais autre chose, et d'ailleurs je passe du temps sur le forum, mais je ne touche plus à ma box depuis plusieurs mois (un ou 2 modules inclus récemment, mais aucun dev LUA depuis cet hiver). Et comme mon code est relativement propre, je n'ai pas besoin d'y toucher, ma box résiste assez bien à ses propres bugs internes. Tout au plus j'ai ajouté quelques lignes dans GEA pour affiner mes scénarios, liés aux nouveaux modules inclus ou à nos habitudes de vie. Au contraire, je profite plutôt bien de ma box domotique, par exemple il y a peu, un clic sur un bouton de VD a suffit pour passer en mode été et couper le chauffage (radiateurs électriques, pompe à chaleur), donc c'est plutôt appréciable. Bref, pas le courage pour l'instant d'aller voir ailleurs, car il faudrait tout refaire, et j'ai justement envie de profiter un peu de ma domotique et surtout j'ai autre chose à faire en ce moment En effet, ça avait été remonté par Fredric je crois, encore une nouveauté qui n'était pas dans le changelog....

Jojo non c'est pas ça. Je comprends ton besoin d'avoir le code le plus rapide possible, car j'ai le même besoin. Sauf que selon le contexte, la façon d'y arriver n'est pas la même. Partons du postulat suivant : - une écriture est 10 fois plus longue qu'une lecture (pour les chiffres exacts, se référer au benchmark de Steven, je n'ai plus les chiffres en tête) - pour les calculs, on dira donc qu'une écriture prend 10 unités de temps, tandis qu'une lecture ne prend qu'une unité de temps Prenons l'exemple suivant : - une boucle tourne toutes les 10 secondes Donc au bout de 1 minutes, j'ai fait 6 passages dans la boucle : - Si la VG a été écrite à chaque passage, j'ai donc consommé 10*6 = 60 unités de temps - Si la VG est lue à chaque passage, j'ai donc consommé 1*6 = 6 unités de temps (10 fois moins, c'est logique puisqu'on est parti du principe qu'une écriture est 10 fois plus longue qu'une lecture). Maintenant pour optimiser son code, il faut savoir quelle est la fréquence (= quelle est la probabilité) que la nouvelle valeur de la VG soit différente à chaque passage dans la boucle. Si la probabilité = 100%, alors inutile de vérifier l'ancienne valeur de la VG, il vaut mieux écriture directement. Si la valeur n'est modifiée qu'une seule fois durant un intervale de 1 minutes, alors il est intéressant de procéder à la vérification préalable : - 1 lecture de l'ancienne valeur de VG à chaque passage de boucle => 1*6 = 6 unités de temps - 1 seule écriture => 1*10 à 10 unités de temps => Soit un total de 6 + 10 = 16 unités de temps => gain de 60 - 16 = 44 unités de temps !!! C'est super intéressant en terme de performances, et ça limite l'usure de la Flash (1 écriture au lieu de 6), et on limite les risque de plantage du HCServer (error 503) Je te laisse calculer le ratio exact de rentabilité à partir duquel il devient intéressant de faire une vérification systématique de l'ancienne valeur de la VG (getValue) avant sa modification (setValue). Pour que le calcul soit exact, il faut prendre les résultats du benchmark de Steven pour avoir une estimation fiable de ce que j'ai appelé "l'unité de temps" dans cet exemple.

Ton utilisation des VG en tant que compteurs expliquerait parfaitement pourquoi tu es celui qui a le plus de 503, et donc confirme un peu plus ma théorie. Pour limiter les dégâts, tu peux déjàremplacer ton setValue par un getValue() puis un "if" et enfin un setvalue().