MAM78

Ca c'est fait J'ai réussi à créer un VD qui écrit dans la Log de mon NAS Synology A vous de tester et faire vos commentaires. Si vous avez une idée pour transposer ce VD en Scène je suis preneur de tous vos conseils.

J'ai créé un VD avec le code ci-dessus dans un bouton. Il semblerait que la commande Net.FUdpSocket() ne soit pas disponible depuis une scène ? Vous auriez une idée pour en faire un scène ?

Envoyer vos logs dans le Centre des journaux sur un serveur Syslog tel que de votre NAS & Routeur Synology Voici un exemple de Logs collectées sur le NAS & Routeur Synology : Nota : Pour les Routeurs Synology il est nécessaire de les équiper d'un disque dur pour pouvoir y stocker les logs Cela permet notamment : de consolider dans un même endroit tous types de messages (Erreur, Log de traitement, Arrêt/Marche de l'Alarme (en identifiant qui), debug, ...) et ceci même en provenance de plusieurs HC2 de bénéficier de leur archivage selon ses propres critères, contrairement à nos HC2 qui purgent automatiquement ses Logs dans les VD et Scènes sans que l'on puisse avoir la main dessus. de consulter/analyser ces messages sur les NAS & Routeurs Synology, ou autre solution d'analyse de logs, avec de nombreux filtres/critères : Périodes (de telle date/heure à telle date/heure) Niveau de gravité (sévérité (voir ci-dessous) Nom d'hôte (HostName) Programme (Nom de Module Virtuel ou Scènes) Catégorie (voir ci-dessous) de générer des notifications (Mail) selon les niveaux de gravité (envoyé par votre NAS Synology) d'exporter ces logs au format (HTML et CSV) de transférer ces logs sur un serveur Syslog (cela peut être intéressant pour les professionnels qui souhaitent avoir une visibilité de ce qui se passe de grave sur les box de leur clients) de limiter les écritures de logs sur notre cartes mémoire de notre HC2 et ainsi d'augmenter sa durée de vie d'indiquer avec une variable globale ou locale pour nos VD/Scènes si leurs traces doivent être stocker sur le Centre de journaux (Syslog) ou affiché dans la log du VD/Scène. Ces Logs sont structurés et normalisés de la façon suivantes : Date et Heure d'émission, Nom de l'équipement ayant généré le log (hostname ou adresse IP). Intéressant, si par exemple vous avez plusieurs HC2. Catégorie standardisé, information sur le processus qui a déclenché cette émission 0 = kern : message provenant du noyau 1 = user : messages utilisateur (générique) 2 = mail : provient de la messagerie électronique 3 = daemon : concerne un démon sans classification particulière (serveur DNS, NTP, etc.) 4 = auth : concernent l'authentification 5 = syslog : message du serveur syslogd lui-même 6 = lpr : provient du sous-système d'impression 7 = news : message du sous-système Usenet (notamment du serveur NNTP — Network News Transfer Protocole, ou protocole de transfert des nouvelles sur le réseau — gérant les forums de discussion) ; 8 = uucp : messages du sous-système UUCP (Unix to Unix Copy Program, ou programme de copie d'Unix à Unix, un vieux protocole employé pour faire circuler entre autres des messages électroniques) ; 9 = clock daemon 10 = authpriv : concernent l'authentification 11 = ftp : concerne le serveur FTP 12 = NTP subsystem 13 = log audit 14 = log alert 15 = cron : provient des services de planification de tâches, cron et and 16 à 23 local0 à local7 : réservés pour les utilisations locales le niveau de gravité (sévérité) standardisé 0 = émerge : « Au secours ! » le système est probablement inutilisable 1 = alert : vite, il y a péril en la demeure, des actions doivent être entreprises immédiatement 2 = crit : les conditions sont critiques pour le système 3 = err : erreur de fonctionnement 4 = warn : Avertissement (une erreur peut intervenir si aucune action n'est prise) 5 = notice : Événement normal méritant d'être signalé 6 = info : message informatif 7 = debug : message de débogage (mise au point) un identifiant du processus ayant généré le log (dans notre cas ça peut être le nom de VD ou de la scène à l'origine de l'émission de la log) un corps de message (libre à vous de mettre ce que vous voulez) Pour pouvoir recevoir ces logs sur votre NAS ou Routeur, il convient préalablement : d'installer le Package Centre des journaux disponible depuis le centre de paquets (faire une recherche du paquet avec le mot : centre) voir ci-dessous. de paramétrer la localisation de la Destination de Stockage pour les Archives en (voir ci-dessous) créant et en sélectionnant un dossier sur l'un des volumes de votre NAS ou Routeur Synology configurant les règles d'archivage de vos logs Créer et enregistrer une règle pour la réception des journaux avec les éléments suivants : Choisissez un nom de règle (c'est à votre choix) Définir le type de journal = Format BSD Définir les protocole de transferts = UDP Configurer le port = 514 Vous pouvez également (pas obligatoire) configurer des règles de notifications selon les critères de gravité et éventuellement quelques mots-clés : Fin de la configuration de votre NAS Maintenant sur votre HC2 : A) Il faut : 1) Charger le VD "Message Syslog" fourni ci-dessous, puis : a) Mettre dans vos paramètres du VD : l'IP de votre Syno dans "Adresse IP:" le port UDP "514" dans "Port TCP:" b) Ajouter et associer l'icône (fournie ci-dessous) à votre VD et associer également cette même icône au bouton du VD 2) Charger la Scène "Message Syslog" fournie ci-dessous, puis : a) modifier dans le code LUA de la scène (voir code ci-dessous) : l'ID du VD (ici 179) que vous avez chargé ci-dessus l'ID de la scène (ici 40) que vous venez de charger b) Ajouter et associer l'icône (fournie ci-dessous) à votre Scène ----------------------- -- User settings to be changed ----------------------- local vd_id = 179 -- id number of the corresponding VD "Syslog Message" local sc_id = 40 -- id off the presence scene 3) Charger le VD "Message Syslog Demo", puis : a) modifier dans le code LUA du VD (voir ci-dessous) : l'ID de la scène "Message Syslog" (ici 40) que vous avez chargé précédemment ----------------------- -- User settings to be changed ----------------------- -- remplace the value 40 with the id of your Scene "Synology Message" local id_Scene_Syslog_Message = 40 4) Tester le fonctionnement dans vos VD/Scènes en ajoutant la commande (le code) ci-dessous : fibaro:startScene(id_Scene_Syslog_Message, {{sev = "warning"}, {orig= "Test Syslog Message"}, {mess = "Text for à warning"}}) 1) remplacer dans la commande ci-dessus les valeurs : "warning", par le nom de la sévérité selon les valeurs (voir explication au début du Toto) : "emergency", "alert", "critical", "error", "warning", "notice", "info", "debug" "Test Syslog Message", par le nom du VD ou de la scène à partir duquel vous souhaitez envoyer votre message. "Text for à warning", le message correspondant à l'événement que vous voulez faire apparaitre dans la Syslog C) Eventuellement adapter le VD et la Scène selon vos besoins Historiques des versions : 2017-03-03 : V2.0 = Adaptation pour en faire une Scène qui peut être appelée depuis nos VD ou Scènes avec un passage de paramètres (ceux correspondants aux différentes parties de logs indiqués en début de Tuto) 2017-02-26 : V1.0 = Version initiale Evolutions à venir : Corriger le problème lorsque 2 messages sont envoyés dans la même minutes. Il s'agit d'un problème lié au fait de l'usage d'un VD et d'une Scène puisqu'il n'est pas possible des s'assurer que les messages soit traités de manière séquentiel. Sauf si l'un de vous me trouve une solution. Pour le moment je ne vois pas Fusionner/Intégrer le VD dans la Scène dès que j'aurais trouvé le moyen de remplacer la fonction Net.FUdpSocket() par d'autres commandes compatibles à la fois pour les scènes et les VD. Je suis également preneur de toutes suggestions d'améliorations (fiabilisations, optimisations, ...) Fichiers joints : VD : VD Syslog_Message V0.1.vfib.json Scène : Scene Syslog Synology V0.1.lua VD Demo : VD Syslog_Message_Demo V0.1.vfib.json Source format Lua :

Merci @Lazerpour la suggestion. J'ai installé sur mon synology le paquet Centre des journaux qui permet de consulter les logs de mon syno. Etant encore très novice en LUA, je veux bien essayer mais je vais avoir besoin d'aide notamment sur la partie écriture du code LUA qui permettrait d'écrire dans la log de mon syno. Est-ce que tu pourrais m'orienter sur un exemple de code LUA pour me connecter et écrire dans la log du syno ?

Effectivement watchdog, c'est ce à quoi j'ai pensé au moment ou j'ai validé ma question Il n'est pas possible d'écrire sur la clef USB de sauvegarde dans un fichier dédié aux log. Avec en parallèle une scène qui s'occuperait d'envoyer des notifications sur la détection de messages les plus critiques mais également de faire des purges pour éviter de saturer la clef ?

un certain nombre (aléatoire ou fixe) est-ce que ces logs sont archivables et est-ce que l'on peut les lire ?

concernant ta suggestion j'ai écrit ceci, ici : https://www.domotique-fibaro.fr/topic/9767-hc2-hcl-version-4110-stable-04012017/?page=29#comment-155610 Quid de la durée d'historisation et du volume des messages historiés dans la scène ?

Pourquoi pas possible depuis un VD ?

Une nouvelle suggestion. Créer une scène (bibliothèque) qui contiendrait un ensemble de fonctions/procédures dont le nom de la fonction/procédure serait le premier paramètre suivi de ses paramètres propres Pour contourner le problème de retour de valeur de la fonction/scène, je pense à la solution suivante : créer une variable globale au nom de la fonction et qui prendrait la valeur de retour souhaitée à chaque appel et qui pourrait ensuite être testé dans le code du VD ou scène appelant la fonction. J'ai juste un crainte à ce sujet, lorsque cette fonction sera appelée de façon quasi simultané ou en parallèle, je ne suis pas certain du coup que la valeur de retour corresponde bien celle générée par le bon VD ou scène ayant appelée la fonction. Si vous avez d'autres idées pour ce retour de valeur de la fonction/scène, je suis preneur. Comme par exemple : fibaro:startScene(20, {{fonction = "nomfonction"}, {param1 = "Valeur 1"}, {param2 = "Valeur 2"}}) if fibaro:getGlobal("Retour_nomfonction") then ... else ... end Dans la scène 20, serait alors exécutée la fonction correspondantes selon le nom du premier paramètre (fonction) accompagnée de ses propres paramètres

Je vous propose de poursuivre cette discussion sur la fonction fibaro:args() dans le post dédié que j'ai créé à cette effet. C'est ici que ça se passe :

@Lazer Désolé mais comme indiqué dans mes post précédent : https://www.domotique-fibaro.fr/topic/10130-passage-de-paramètres-pour-une-scène/#comment-155623 L'appel depuis un VD fonctionne parfaitement. Mon correcteur orthographie m'avait joué un mauvais tour. fibaro transformé en figaro Merci à @Krikroff d'avoir refait un test qui à permit de confirmer que cela marche très bien également avec un VD. Tu vas pouvoir faire ce que veux : code commun entre les boutons.

Est-ce qu'il existe une autre fonction disponible pour les scènes en remplacement de la fonction Net.FTcpSocket, afin de contourner le problème.

Merci grand maitre. Donc un fonction disponible pour l'ancien moteur LUA 5.1 mais non disponible pour le moteur 5.2. Cf. ce que tu m'indiquait ci-dessous : VD = Ancien moteur LUA 5.1 Scènes et plugins = Moteur LUA 5.2 de la V4.xxx Décidément ils ne veulent vraiment pas être homogène dans leur DEV nos amis FIBARO. Je vais donc être obligé de passer par l'activation de bouton dans un VD. Ca va pas me simplifier la maintenance de mon code, ça ! Moi qui pensait pouvoir créer une scène générique pour commander mon hyperion sans passer par un VD. Ben c'est loupé.

Effectivement ça marche nickel. Ca va permettre de nous simplifier la maintenance de nos codes. J'ai compris pourquoi j'avais une erreur, le put.. de correcteur orthographique m'avait remplacé fibaro par figaro.

Je viens de reprendre une partie code du VD Hyperion pour l'intégrer dans une scène et je n'arrive pas à le faire fonctionner. Voici le code : --[[ %% properties %% events %% globals --]] local _deviceIp = "192.168.0.40"; local _devicePort = "19444"; tcpSocket = Net.FTcpSocket(_deviceIp, _devicePort); tcpSocket:setReadTimeout(200); local commande = [[{"command":"effect","priority":40,"effect":{"name":"Police Lights Solid"},"duration":14400000}]]; local bytes, errorCode = tcpSocket:write(commande); tcpSocket:write("\r\n"); tcpSocket:disconnect(); il génère l'erreur suivante sur l'instruction Net.FTcpSocket : [DEBUG] 00:52:32: line 8: attempt to index global 'Net' (a nil value) Pourriez-vous SVP m'indiquer où est l"erreur ?

en 2024 ? je suppose qu'il n'y a aucune date d'avancée ?

Bonjour la convergence du code et l'intégration continue chez Fibaro

Sauf pour l'usage dans les VD pour lesquels l'appel de la scène par passage de paramètres ne semble pas fonctionner. Après un check par @Krikroff l'appel depuis un VD fonctionne très bien aussi

@Krikroff Ton post signalant l'existence de ta scène Notification center @Krikroff même pas drôle, tu l'as déjà fait en bonne partie Ce ne serait donc plus nécessaire de mettre ta fonction Notify dans la page de code a l'origine de la demande de notification. Compte-tenu de cette nouvelle possibilité de faire un passage de paramètre lors d'appel de scènes, qu'est-ce qui faudrait adapter dans ton code pour passer les paramètres et peut-être sans la nécessité d'utiliser d'une variable globale ? Ce serait top d'ajouter les notifications interactives à ta scène. Cf. post de @mprinfo disponible ici : Notification interactive pour lancer une scène Par ailleurs, est-ce que tu a fait évoluer ta fonction depuis la version 1.0.1 et si tel est le cas pourrais-tu STP nous en faire profiter ?

Je vous propose de poursuivre vos idées et suggestions de fonctions génériques sous le lien ci-dessous afin de les centraliser dans un même topic.

Attention : Après quelques temps d'utilisation, je me rends compte d'une certaine limite à l'usage que cette solution, notamment lorsque l'on veut la solliciter la scène de façon intensive. En effet lorsqu'il y a un grand nombre d'appels de la scène créée dans un laps de temps très court, comme par exemple inférieur à la seconde (ou plus si, la scène effectue un grand nombre de traitements qui durent un certain temps), vous aurez un violant plantage de la Scène ou du VD qui sollicite la scène créée/appelée. Cela arrive dès lors que l'on dépasse le nombre maximum d'exécutions simultanées (voir paramétrage Max. running instances) de la scène créée. Sachant que le maximum est limité à 10 instances simultanées. Donc avant de se lancer dans la création d'une scène comme un équivalent d'une fonction, il convient de se poser la question, combien de fois cette scène peut être appelée en simultané.

Espace réservé pour une liste des fonctions génériques qui seront développées ou suggérées sur la base de cette nouvelle fonction. Suggestions : Notifications centralisée (Mail, SMS, Push, Messages vocaux, ...) avec une gestion des identifiants des destinataires (adresses mail, ID de téléphone). Evolution à venir sur la fonction Notify de @Krikroff disponible ici : Notification Center Associer à un VD une ou de scènes reprenant les codes répliqués dans chacun des boutons du VD. Avec je l'espère de nouvelles versions des VD du forum mettant à profit cette centralisation du codes pour en simplifier leur maintenance. Suggestion de @Lazer Créer une scène (bibliothèque) qui contiendrait un ensemble de fonctions (qui ne nécessite pas de retour de valeur, soit des procédures) dont le nom de la fonction/procédure serait le premier paramètre suivi de ses paramètres propre à cette fonction/procédure. Suggestion de @MAM78 Disponibles : Centraliser l'ensemble des logs de toutes les scènes et VD. Notamment celles les plus critiques qui permettrait d'avoir une vision globale sur les problèmes rencontrées. Suggestion de @Gazous ==> C'est fait par @MAM78 via un serveur Syslog (exemple Synology) est c'est disponible ici : Envoi de Logs vers un serveur syslog (exemple : Synology)

Fonction figaro:args() Passage de paramètres pour les scènes Suite à la découverte de @Steven d'une nouvelle fonction figaro:args() dans la version 4.110 qui permet de faire passer des paramètres lors de l'appel d'une scène. Je vous propose d'ouvrir ici un nouveau sujet dans lequel nous pourrions échanger sur les nouvelles possibilités offertes par cette fonction. Notamment la simplification de la maintenance de nos codes LUA. Comme par exemple : la création de fonctions génériques qui pourraient être appelées depuis l'ensemble de nos scènes, modules virtuels et appareils externes sans avoir à dupliquer le code dans chacun d'eux. Dans le 2ème post, vous trouverez les suggestions et nouvelles scène utilisants cette nouvelle fonction. Vous trouverez ci-dessous un exemples d'usage de cette fonction (reprise de l'exemple de @Steven ) pour des Scènes ou Modules Virtuels : 1) Utilisation depuis une scène ou un module virtuel Code la scène ou module virtuel appelant : fibaro:startScene(20, {{prenom = "Steven"}, {nom = "Piccand"}}) Code de la scène appelée : local params = fibaro:args() if (params) then for k, v in ipairs(params) do if (v.nom) then print("Nom : " .. v.nom) end if (v.prenom) then print("Prénom : " .. v.prenom) end end end Résultat dans la fenêtre de debug de la scène appelée : [DEBUG] 16:57:20: Prénom : Steven[DEBUG] 16:57:20: Nom : Piccand 2) Utilisation depuis un appareil externe : Comme par exemple une box domotique utilisée en passerelle (au hasard, Jeedom, FHEM, Zibase, etc), des scripts Shell (CURL), des pages Web (PHP), etc. (sauf IPX800 pour le moment) source @Lazer URL à appeler en POST : /scenes/123/action/start Données à envoyer en POST : {["args"]=args})

Je viens de faire quelques tests. Il semblerait que cela ne fonctionne que de scène à scène et non de VD à scène. Dommage, peut-être pour une prochaine version ? Ca fonctionne depuis un VD également. A noter que les PRINT (fenêtre de debug) ne s'affichent que dans la fonction appelé et non dans la fenêtre de debug de la scène appelante. Donc pas possible de crée une fonction générique de gestion des traces (fenêtre de debug) et avoir les traces dans les scènes appelantes pour suivre l'exécution de sa scène en mode debug. Par-contre l'inverse est du coup possible, c'est d'avoir dans un seul endroit et même endroit des traces de nos traitements. Comme pas exemple une centralisation des traces les plus importantes (genre gros messages d'alertes) avec leur historisation. Savez-vous quelle est la durée de cette historisation et le nombre maximum de ligne dans la fenêtre de debug ?

ah bon !!! mince alors