Lazer

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

Bah écoute j'ai constaté que 3 câbles dans une gaine de 25 passe mieux que 2 dans une 20.J'ai même pas fait de calcul de diamètre, mais 20mm, ce n'est pas le diamètre extérieur ? Donc tu as beaucoup moins dedans. Ce qui explique pourquoi les 2 câbles passent mal.

@pepite, tu auras du mal àpasser 2 câbles que tu as linké en premier post dans une gaine de 20. J'ai le même câble, il a un double blindage, donc épais et rigide. Par contre, comme je le disais, 3 câbles passent bien dans une gaine de 25mm pour peu que tu n'aies pas de coude (la technique est d'enfiler les câbles dans la gaine avant d'immobiliser celle ci fans les murs).

[emoji38] ça fonctionne chez moi

C'est bien ce qui me semblait, la presse en ligne high-tech (tout comme les autres secteurs d'ailleurs...) recherche avant tout le clic au détriment d'une information fiable et vérifiée. Voici donc un article sérieux qui essaye de mettre au clair cette affaire : http://www.sxminfo.fr/103470/12/11/2015/la-panne-informatique-dorly-liee-a-un-serveur-tournant-sous-windows-nt-3-1/

Bravo Yohan

Ce qui compte, c'est d'arriver à faire fonctionner sa domotique comme on l'entend. Le LUA n'est pas une fin en soit, et si tu arrives à tout faire fonctionner via GEA ou des scènes en mode bloc, il n'y a pas de raison de perdre du temps avec LUA. Sauf si bien sà»r tu considères le LUA comme un exercice cérébral sain Mais n'oublie pas que le LUA est le langage de la HC2, que tu ne garderas pas éternellement, et rien ne dit que la prochaine box utilisera le LUA (même si plusieurs box utilisent le LUA en domotique, tels que Vera ou Domoticz). Le LUA est surtout utile si tu souhaites développer tes propres scènes ou modules virtuels, afin de répondre à des problématiques que personne n'a abordé sur le forum, ou que tu souhaites adapter du code existant à ton usage. Tout comme le Visual Basic permet d'étendre les fonctionnalités d'Excel par exemple pour développer des mini-applications puissantes.

Avec la V3, tu peux aussi piloter les volets roulants, mais ça te bouffe 2 relais par volet je crois. C'est ce qu'utilise @Nico entre autre.

ah oui très bien ça, j'avais oublié

Somfy ne fait pas de volets de toits à ma connaissance, ils laissent ça à leur partenaire Velux. Sur le toit, à part Velux, c'est difficile de trouver un autre fabricant. Il y a Fakro aussi je crois. Avec les Velux, il faut du filaire, et utiliser le nouveau module Qubino à inversion de polarité. Le souci c'est qu'il ne fonctionne pas du tout avec la HC2.

C'était la 3.11 for Workgroup qui ajoutait le support de TCP/IP je crois.

Ca sens le gros troll quand même. La news dis juste que le système informatique tourne sous Windows 3.1, mais on ne sait pas si c'est la cause du plantage. Si ça se trouve, c'est juste l'alimentation qui a lâché. Et j'ai même envie d'ajouter, si peu de plantage en tant d'années, ça démontre la robustesse du système. Je suis bien d'accord avec Syris, pourquoi migrer un système qui fonctionne bien ?

Super merci Pitp2