Lazer

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

si tu ne peux pas utiliser le countscenes, alors il faudra utiliser l'analyse par message d'erreur.... tu as donné en premier post le message d'erreur LUA qui s'affiche, donc dans le watchdog il suffira de paramétrer un string.match() sur la chaine en question. Donc la même erreur que tu as dans ta scène ne devrait pas se produire, car le watchdog n'analysera pas la même réponse JSON que celle de ta scène. En pratique, le watchdog est susceptible de planter car il a les mêmes limitations que toutes les autres scènes/VD de la HC2, mais le risque que les 2 plantent en même temps (VD/Scène et watchdog) est très faible. Ou alors, il faudrait déporter le watchdog sur une machine externe, telle qu'un NAS avec du PHP. Mais ce n'est plus intégré à la HC2, et ça dépend d'un matos externe que tout le monde n'a pas à disposition.

en fiat ça sera une boucle infinie, donc je pensais mettre un sleep de 60s, configurable bien sur. après faudra faire un watchdog du watchdog, puis un watchdog du watchdog du watchdog, puis ....

hihi pas de souci et tant mieux si ils prennent en charge ce genre de problème, c'est cool. Bon sinon pour le watchdog, ça sera une scène (seul moyen d'utiliser countScenes() ), donc ça simplifie pas mal les choses, car il n'y aura pas de virtual device à mettre à jour avec de belles icones et de beaux labels La scène sera autonome, c'est à dire que si elle détecte un plantage, elle redémarre immédiatement le VD/Scène concerné, avec éventuellement une notification (comme pour mon VD Network monitor) Pour configurer la scène, il y a aura une variable en début de script pour préciser les ID à surveille, les notifications à envoyer, etc.

Justement j'ai un peu de temps ces jours ci En plus mes PC sous Windows fonctionnent tous très bien. En cas de panne, il suffit de remplacer le composant défectueux, et c'est reparti, pas besoin d'immobiliser au SAV. Un gros troll velu se cache dans ce message

Si Krikri àle temps pour le faire, le résultat sera forcément au top, mais sinon j'avais prévu de m'y mettre.

Et on peut la rooter ?

Bon j'ai trouvé comment récupérer le Debug des modules virtuels via l'API : Pour la main loop : /api/virtualDevices/15/debugMessages/0 Pour les boutons : /api/virtualDevices/15/debugMessages/1 /api/virtualDevices/15/debugMessages/2 /api/virtualDevices/15/debugMessages/3 ... . Pour les scènes, j'avais précédemment partagé une URL, mais ça date de la v3, je pense que ça va être déprécié et supprimé un jour ou l'autre. La nouvelle API à utiliser en v4 est : /api/scenes/14/debugMessages . Donc pour détecter un plantage d'une main loop d'un module virtuel ou une scène, on peut envisager plusieurs possibilités : rechercher une chaine particulière dans les messages de debug => utile pour détecter les erreurs classiques du style "attempt to concatenate a nil value" comparer le timestamp du dernier message avec le timestamp courant => utile pour détecter un code qui serait mort sans afficher de message d'erreur spécifique compter le nombre de scènes actives avec fibaro:countScenes(14) => attention cette commande n'est valide que depuis une scène, les valeurs retournées depuis un VD sont farfelues => peut-être utilisé très simplement pour GEA, qui doit normalement toujours avoir au minimum 1 instance en fonctionnement. Reste maintenant à écrire un Watchdog pour monitorer tous les modules virtuels et scènes critiques, puis avertir l'utilisateur par notification, et redémarrer automatiquement le module/scène planté. On a maintenant en main tous les outils pour résoudre les problèmes de plantage inexpliqués.... sauf l'erreur 503.

J'ai des clients chez qui ils ont mis ça dans leurs toilettes. 2 options : - Tu te dépêche - Ou tu apprécies le noir, et tu t'endors