Besoin daide Catcher Une Erreur Lua

[Gazous]

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.

[jojo]

je sais qu'en interne la box utilise des fonction son decode, par exemple pour des instructions fibato:getName ou fibaro:getRoom

peut-être une piste ?

[Gazous]

Merci Jojo, c'est peut-être une piste mais je n'utilise pas ses fonctions dans la scène en question.

[Gazous]

Bonjour, petit UP sur le sujet car j'ai ànouveau reçu cette erreur que je ne sais pas comment catcher.

Merci d'avance pour votre aide.

[Berale64]

ça peut surement aider: http://www.lua.org/pil/8.4.html

[Lazer]

Oui faut utiliser pcall(), le maitre de cette fonction, c'est.... devinez.... Krikroff !! Il me semble que Steven l'utilise aussi.

Il y a  2 ou 3 exemples sur le forum.

[Gazous]

Le souci c'est que j'utilises pcall partout depuis les premiers pas en LUA et le code en question est exécuté de cette manière...

[Lazer]

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.

[Gazous]

Hello Lazer, je découvre ton message à  l'instant. Je ne l'avais pas vu passer et le problème vient à  nouveau de se produire sur une de mes scènes donc je vais tester cette API, merci ! 

[Lazer]

Ok tiens moi au courant.

[jojo]

@ gazou,

tu nous posteras ta solution ?

Merci

[Lazer]

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.

[jojo]

Lazer, toujours aussi GEANT !

[BenjyNet]

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

[Lazer]

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.

[BenjyNet]

Milles excuses Lazer... fais toi plaisir  

[Gazous]

Ça me dit bien de le faire aussi mais problème de temps en ce moment. Ma Todo list est trop longue. En plus mon Macbook est en SAV àl'Apple Store pour une semaine [emoji30]

Envoyé de mon iPhone en utilisant Tapatalk

[Lazer]

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

[BenjyNet]

Oh putain ! J'ai pas osé la faire mais toi tu l'as fait.... :D

[Gazous]

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 [emoji5]

Envoyé de mon iPhone en utilisant Tapatalk

[Lazer]

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.

[BenjyNet]

[mode ironie On] Huhu la scène elle va se déclencher toutes les 30s  [mode ironie Off]

[Lazer]

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 ....

[Gazous]

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

[Lazer]

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.