MAM78

Je ne me souviens plus, mis maintenant ça marche. C'est l'essentiel pour moi

Ca y est, j'ai enfin réussi à automatiser la relance de ma scène via WatchDog. Je pense que ça venait de la ligne que j'avais ajouter à WatchDog. La ligne ci-dessous arrive bien à relancer la scène. {type = "Scene", id = 21, match = {text="", interval=0}, no_match = {text=""}, count=1, restart=true, notification = {}} -- Surveillance Station Yessss. En attendant la correction du bug par les DEV de Fibaro

Moi, j'ai intégrer le code de @Titof_44 indiqué ci-dessous mais ça ne marche pas

J'ai déjà ajouté le code Stop/Start dans le WatchDog mais rien n'y fait. Ca ne veut pas redémarrer

J'ai bien une nouvelle keyfob en V4.110 mais je n'ai pas osé faire l'update avec la beta. J'ai pas trop envie d'avoir les mêmes galères que toi

Dommage effectivement sur les IPX. j'ai bien fait d'attendre vos tests Sinon c'est faisable avec d'autres solutions qui utilise l'API ? @Lazer tu aurais un autre exemple à donner pour illustrer la chose ?

Salut @Sakkhho, Oui elle plante toujours et je n'arrive toujours pas à la relancer avec Watchdog Je n'ai pas essayé la beta 4.111 (j'ose pas pour le moment, certain ont eu des problèmes) notamment avec les nouvelles télécommandes KeyFob. Si tu l'as chargé, tu pourrais essayer STP ?

Ok, @Krikroff, @Steven si vous passer par ici. un petit coups de main serait le bienvenu.

Je vous laisse débuguer Dès que c'est bon, vous pouvez me formaliser un exemple succinct afin que je l'ajoute en début de Tuto.

merci @Lazer si au passage tu quelques conseils à me donner pour le transposer mon vd en scène puisque la fonction Net.FUdpSocket() n'est pas disponible dans une scène

@Lazer : C'est fait, voir mon Tuto ci-dessous. En fait, pas si compliqué que ça. Merci de m'avoir motivé et challengé pour me lancer dans la création d'une scène (un VD en l'occurence pour le moment) qui génère des logs au format standard syslog, qui pourrait être envoyer vers n'importe quel Linux (y compris les Synology). Là c'est propre et professionnel.

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.