Aller au contenu

Catcher Une Erreur Lua


Gazous

Messages recommandés

Bonjour,

 

J'ai une scène assez simple qui tourne en permanence et qui a pour but de récupérer la trame JSON d'un IPX pour stocker le résultat dans une VG.

Cela fonctionne très bien sauf que dans certains cas, j'ai une erreur que je n'arrive pas à  contourner et qui plante ma scène.

 

Voici l'erreur en question :

 

[ERROR] 12:48:06: LUA error: /usr/share/lua/5.2/json/decode/util.lua:35: unexpected character @ character: 1 0:1 [d] line:

[ERROR] 12:48:06: d

 

Cela se produit de manière aléatoire, peut-être une fois par mois et cela m'oblige à  relancer la scène manuellement.

Est-ce que quelqu'un a déjà  rencontrer ce genre de souci et trouvé un contournement.

Ce que je ne comprends pas c'est que je n'appelles pas de méthode decode sur le json dans cette scène...

 

Merci d'avance pour votre aide.

Lien vers le commentaire
Partager sur d’autres sites

  • 3 semaines après...
  • 3 semaines après...

Voici une API qui peut t'aider à  surveiller ta scène depuis une autre scène :

/api/sceneDebugMessages?id=22

Remplacer 22 par l'ID de ta scène qui plante.

 

Tu aurais accès à  tous les messages de la zone de débuggage, avec même le timestamp !

Si tu fait un string.match sur l'erreur, tu peux la détecter, et forcer le redémarrage de la scène automatiquement, sans avoir à  la redémarrer manuellement.

 

Exemple :

[
{

    "timestamp": 1443813290,
    "type": "DEBUG",
    "txt": "<span style=\"color:grey; padding-left: 125px; display:inline-block; width:80%; margin-top:-18px; padding-top:-18px; text-align:left;\">[ 198 | n/a ] Add Property        : ajout de la tâche pour lancement instantané (ID: 53) [Time,22:00,Sunrise] [Value,80,50]</span>"

},
{

    "timestamp": 1443813290,
    "type": "DEBUG",
    "txt": "<span style=\"color:grey; padding-left: 125px; display:inline-block; width:80%; margin-top:-18px; padding-top:-18px; text-align:left;\">[ 198 | n/a ] Add Property        : ajout de la tâche pour lancement instantané (ID: 56) [RestartTask,54]</span>"

},
{

    "timestamp": 1443813290,
    "type": "DEBUG",
    "txt": "<span style=\"color:green; padding-left: 125px; display:inline-block; width:80%; margin-top:-18px; padding-top:-18px; text-align:left;\">GEA Version 5.40    :  en exécution...   </span>"

}
]

.

 

Il y a aussi cette API pour les VD, mais je n'arrive pas à  la faire fonctionner, car je n'ai pas trouvé les bons arguments :

/api/virtualDeviceDebug

En mettant id=xx je n'obtiens rien, peut-être faut-il ajouter un autre paramètre pour spécifier le bouton/mainloop.

Lien vers le commentaire
Partager sur d’autres sites

  • 1 mois après...

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.

  • Upvote 3
Lien vers le commentaire
Partager sur d’autres sites

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.

 

 

Krikri si tu nous entends :D :D :D

Lien vers le commentaire
Partager sur d’autres sites

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 :D

  • Upvote 3
Lien vers le commentaire
Partager sur d’autres sites

Rhoo !!! Pas gentil !

Je n'ai pas de soucis particulier c'est juste un remplacement d'écran pris en charge par Apple même hors garantie suite àune identification d'un problème potentiel de revêtement antireflet sur la dalle. Ne soyez pas mauvaises langues en 15 ans d'utilisations de Mac (MacBook et iMac) je n'ai jamais eu àavoir affaire au SAV et cette fois-ci ce n'est pas une panne mais du préventif pris en charge hors garantie. Vous allez me dire, vu le prix c'est normal etc... Bref je respecte bien sûr votre avis, chacun ses goûts. Je tenais juste àapporter cette précision

Envoyé de mon iPhone en utilisant Tapatalk

  • Upvote 1
Lien vers le commentaire
Partager sur d’autres sites

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 :P

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.

  • Upvote 3
Lien vers le commentaire
Partager sur d’autres sites

Tiens alors justement c'est ce que je le disais : sachant que mon erreur se produit de façon aléatoire dans le traitement d'une trame Json bha la scene Watchdog risque de rencontrer le même souci...

Dans le cas de ma scene je crois que après ce tyoe d'erreur CountScene doit renvoyer 0 puisque j'utilise un appel http asynchrone et que c'est dans le resultat de l'appel que je fais un sleep pour relancer le suivant etc. Comme l'erreur se produit dans la fonction exécutée en asynchrone la scene doit àpriori se terminer sur cette exception. Je pourrais peut-être faire autrement.

Envoyé de mon iPhone en utilisant Tapatalk

Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

×
×
  • Créer...