Lazer

Par contre, y'a des SSD c'est vraiment de la m.... et pas adapté à un usage serveur. J'en ai crashé 4 au bout de 15 jours d'I/O soutenus nuit et jour. Remplacés par des Intel qui tournent comme une horloge depuis bientôt 1 an : Le seul souci c'est qu'ils sont presque pleins.....

Soyons positifs, après de longs mois (années ?) d'instabilités, on a maintenant un moteur Z-Wave au top, certainement l'un des plus stables et rapide du marché. Gageons qu'ils arriveront àreproduire ce miracle sur le reste de la box.... RDV en 2016

Bah ouais mais tu le cherches, tu sais bien que les Mac c'est un sujet de troll récurrent

Jojo, regardes les stats de Hardware.fr, tu verras que le pire des SSD est plus fiable que le meilleur des disques durs, donc pas trop de craintes à avoir EDIT : Les taux de retour des composants (13) (bon à quelques exceptions près sur certaines références)

Le Samsung EVO c'est peut être pas le top, mais c'est déjàplus performant que la majorité des SSD du marché, alors ça va quand même Que ce soit pour un PC sous Windows ou sous MacOS (ou LInux, comme ça y'en a pour tout le monde )

ça ne fonctionnera pas, i aura les valeurs 1 et 2. Essaye plutôt : local ID_Smartphones = {200,226} for i = 1, #ID_Smartphones do fibaro:call(ID_Smartphones[i], 'sendPush', Etat) end

Merci pour ton retour Cmoi20

J'avais cru comprendre que ce sont les utilisateurs Jeedom qui ont ce côté intégriste, mais que les développeurs étaient très àl'écoute des améliorations possibles.

Faudrait que tu contactes Cmoi20, il l'a fait dans les 2 sens il me semble.

J'ai ça depuis 3 jours environ, aussi bien pour la T°C que pour HR%. Je pense que Yahoo a modifié son API.....

domotique_device_type permet de lier un device à un type En effet, un même device peut avoir plusieurs types. Par exemple chaque Wall plug a les types Power et Energy Le thermostat SRT321 a les types battery et temperature etc... C'est plus propre, ça permet d'avoir un seul enregistrement dans la table domotique_device par device. Et plus évolutif, car par la suite on peut rajouter des types et les lier aux devices existants. C'est le principe de base d'une base de données relationnelle (SGBD-R)

avec les infos dont je dispose, je n'ai aucune idée du problème, donc impossible de te dire pour le moment.... je ne me souviens pas avoir vu ce message d'erreur

si tu appelles la page http://api-ratp.pierre-grimaud.fr/v2/traffic/rers.json c'est normal dans ton premier post tu mets que c'est http://api-ratp.pierre-grimaud.fr/v2/traffic/rers petite confusion je pense

arf en effet, c'est un tableau (avec le crochet) Essaye comme ça fibaro:debug(jsonTable.response.rers[1].title) fibaro:debug(jsonTable.response.rers[2].title)

avec juste cette image, je ne sais pas vraiment déterminer si c'est hardware ou software. il faudrait voir les 2 boots (normal et recovery) pour mieux comprendre oui je comprends que 1 mois sans box domotique c'est dur....

c'est "response" (an anglais)

pas bon.... cet écran, c'est au moment du boot ? tu peux essayer de faire un film complet du boot ? est-ce que ta box est encore garantie ?

tu veux faire quoi exactement ? déjà essaye ça : fibaro:debug(jsonTable.reponse.rers.title)

je suis d'accord, mais connaissant un peu la politique de Fibaro, j'ai pas trop l'impression qu'ils vont accepter ça.... ils sont tellement persuadés d'avoir la box parfaite.....

Non mais c'est ce que je me tue à dire depuis un moment déjà : les process développé par Fibaro plantent quoi qu'il arrive. Nos scripts créent une charge supplémentaire qui accélère plus ou moins ce plantage, mais nous ne sommes pas responsables des plantages. Donc tant qu'ils ne trouveront pas la solutions à leurs problèmes, on doit faire avec, d'où ce watchdog. Pour le 503, pas d'autre solution que de d'être root et de faire un watchdog au niveau de LInux : surveillance des process, et redémarrage si nécessaire. Sinon, bah c'est le bouton derrière la box....

Oui Sebcbien, on fait avec, on n'a pas le choix. d'où la discussion sur le watchdog dans le topic "catcher une erreur lua" mais on restera limité par la redoutable erreur 503, qui ne peut être résolu que par un redémarrage de tous des process sous LInux (nécessite un accès root, ou alors reboot de la box via le bouton arrière)

rhooo la coquille (mais c'est pas pire que les bagnoles françaises)

Oui Sebcbien je suis bien d'accord. Pour le VD Evénements, ça fait longtemps que j'ai allongé la durée de rafraichissement, au lieu des 3s. Par contre le simple bouton update me suffit, en one-shot, je n'ai pas besoin d'un rafraichissement rapide pendant certain temps. Néanmoins ton approche avec le slider est très intéressante. En revanche, je maintiens qu'il n'est pas normal que la box les process développés par Fibaro plantent en cas de charge modérée. N'importe quel PC, serveur, ou autre peut tenir des charges très importantes pendant plusieurs heures, tant que le refroidissement du processeur est assurée. Au pire du pire, c'est du Intel, le processeur se mettra en sécurité en baissant sa fréquence. Là on est dans un pur problème de logiciel informatique, avec des développeurs Fibaro qui ne savant pas faire leur travail. J'insiste mais la nuance est importante. Et la réponse du support FIbaro qui rejette la faute sur nos scripts est inacceptable.

C'est exactement ce que faisait le Scheduler qui fonctionnait en v3. Je ne sais pas si son auteur a finalement réussi àle porter en v4.

28,6°C