Quick App - Network Monitor

[fastvd]

Le 18/01/2022 à 21:13, Lazer a dit :

Euh non, mais pourquoi tu veux mettre le message dans une VG ?

Si tu veux envoyer à un QuickApp pour faire du TTS, du Telegram, du SMS, ou que sais-je, tu peux utiliser la variable du QA Notif_SMS en précisant le nom du QA cible, et sa fonction. Le message sera passé en paramètre de la fonction.

 

Le paramètre vg dans chaque ligne correspond à une VG qui sera incrémentée de 1.
Par exemple, si ça fait 10 fois que Google ne répond plus, la variable contient 10, j'ai une règle GEA qui reboote la Freebox via le Wall Plug.

Very interesting QA, but very difficult to configure.
1) Can there be more examples of how to describe the section DEVICES = {
example:
1.1) this is how we can see if the HTTP service is available, here the login\password is required, or vice versa
1.2) this is how we can track through shh, here we need to specify so and so..
1.3) also we may or may not track by icmp
2) you write that notifications can be sent to telegrams by specifying the QA ID of the telegram itself and some function...could you show an example?

[Lazer]

Indeed it is quite difficult to configure this QuickApp, as it require some basic network knowledge.

There are many examples on first page that you can inspect to understand the different parameter values.

Then it is up to you to create your custom configuration for devices on your network.

 

As a general rule, I would say it is best to use HTTP mode when possible, because it is not only test whereas the device is powered on, but also if the output is valid, meaning the device is fully operational.

It is easy to implement, you can just open a web page with your favorite browser and look for a text content that que QuickApp is able to interpret.

 

The TCP mode is a more advanced way of testing a device state, when this one does not expose a HTTP service. For instance, you can check SSH connection for a Linux server that as no other exposed services (opened port).

It is more complicated, you can use PuTTY or other similar tool to connect to a specific TCP port and see what text message is returned. But for some services no text message is returned.

 

ICMP (ping) is unfortunately not available in LUA on Fibaro HC3.

 

 

For notifications to specific QuickApp (SMS, Telegram, etc), there is an example in the tutorial on first page, you have to fill in the Notif_SMS variable.

[henri-allauch]

Juste pour info

C'est la première fois que je vois cracher ce QA depuis plusieurs années.

Mais il est reparti seul et pour le moment tout va bien.

Une embrouille sur mon réseau, un accès moire HC3 foireux ? .....

 

[24.03.2024] [11:29:47] [DEBUG] [QA_NETWORK MONITOR_29]: Total memory in use by Lua : 1302.02 KB, CPU consumed : 259.69 ms ( 0.001 % )
[24.03.2024] [11:29:47] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Orange Livebox => 192.168.1.1
[24.03.2024] [11:29:48] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Teracom 181B-CM => 192.168.1.59
[24.03.2024] [11:29:50] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Caméra Bureau => 192.168.1.22
[24.03.2024] [11:29:52] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Caméra Portail => 192.168.1.24
[24.03.2024] [11:29:54] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Caméra Jardin => 192.168.1.28
[24.03.2024] [11:29:56] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Caméra Piscine => 192.168.1.26
[24.03.2024] [11:29:58] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Caméra Four => 192.168.1.27
[24.03.2024] [11:30:00] [DEBUG] [QA_NETWORK MONITOR_29]: Check : DoorBird => 192.168.1.60
[24.03.2024] [11:30:02] [DEBUG] [QA_NETWORK MONITOR_29]: Check : MacLinux => 192.168.1.35
[24.03.2024] [11:30:04] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Google => www.google.fr
[24.03.2024] [11:30:04] [ERROR] [QUICKAPP29]: QuickApp crashed
[24.03.2024] [11:30:04] [ERROR] [QUICKAPP29]: Unknown error occurred: LuaEnvironment: /data/vendor/avhttp/avhttp/impl/http_stream.ipp:2312: void avhttp::http_stream::handle_skip_crlf(const MutableBufferSequence&, Handler, boost::shared_array, const boost::system::error_code&, std::size_t) [with MutableBufferSequence = boost::asio::mutable_buffers_1; Handler = boost::function; std::size_t = long unsigned int]: Assertion `crlf[0] == '\r' && crlf[1] == '\n'' failed.

[24.03.2024] [11:31:14] [TRACE] [QA_NETWORK MONITOR_29]:
[24.03.2024] [11:31:14] [TRACE] [QA_NETWORK MONITOR_29]: - *** QuickApp NETWORK MONITOR - MyInit V: 2.12 - Initialisation après temporisation de 14 secondes *** - ( Démarrage différé version Henri )
[24.03.2024] [11:31:14] [TRACE] [QA_NETWORK MONITOR_29]:
[24.03.2024] [11:31:14] [DEBUG] [QA_NETWORK MONITOR_29]: Using tools library v2.20
[24.03.2024] [11:31:14] [DEBUG] [QA_NETWORK MONITOR_29]: Using Notifications library v2.20
[24.03.2024] [11:31:14] [DEBUG] [QA_NETWORK MONITOR_29]: Add notification quickapp "Notifications" Notif_NWM()
[24.03.2024] [11:31:14] [DEBUG] [QA_NETWORK MONITOR_29]: Add notification user "henri"
[24.03.2024] [11:31:14] [DEBUG] [QA_NETWORK MONITOR_29]: Add notification mobile "iPhone"
[24.03.2024] [11:31:14] [DEBUG] [QA_NETWORK MONITOR_29]: Number of devices to check : 13
[24.03.2024] [11:31:16] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Orange Livebox => 192.168.1.1
[24.03.2024] [11:31:18] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Teracom 181B-CM => 192.168.1.59
[24.03.2024] [11:31:20] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Caméra Bureau => 192.168.1.22
[24.03.2024] [11:31:22] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Caméra Portail => 192.168.1.24
[24.03.2024] [11:31:24] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Caméra Jardin => 192.168.1.28
[24.03.2024] [11:31:26] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Caméra Piscine => 192.168.1.26
[24.03.2024] [11:31:28] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Caméra Four => 192.168.1.27
[24.03.2024] [11:31:30] [DEBUG] [QA_NETWORK MONITOR_29]: Check : DoorBird => 192.168.1.60
[24.03.2024] [11:31:32] [DEBUG] [QA_NETWORK MONITOR_29]: Check : MacLinux => 192.168.1.35
[24.03.2024] [11:31:34] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Google => www.google.fr
[24.03.2024] [11:31:36] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Wes => 192.168.1.54
[24.03.2024] [11:31:38] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Orange Accès Mansarde => 192.168.1.16
[24.03.2024] [11:31:40] [DEBUG] [QA_NETWORK MONITOR_29]: Check : Orange Accès Bureau => 192.168.1.17

[Lazer]

Ah ouais, étrange, je n'ai jamais vu ce message.

Merci pour l'info en tout cas.

 

La HC3 embarque un watchdog intégré qui redémarre les QA plantés automatiquement, ça c'est chouette, et il est probable qu'on ne détecte pas tous les crash de QA vu que ça redémarre tout seul.

[henri-allauch]

Quand j'avais la hc3 qui avait le bug des redémarrages non sollicités, j'avais fait un Qa debug qui récupère cycliquement  les messages d'erreur de la trace (console) et les stockent dans un fichier externe. J'ai pu capter des erreurs de mes Qa (erreur de cas particuliers ou Autres). Je crois que quelqu'un ici stocke les erreurs dans une table de base de données. 

C'est utile car la trace (console) disparaît lors du reboot. Et lorsqu'elle atteint sa taille limite, on pert les infos les plus anciennes.  Et comme tu le dis ci-dessus on peut ne pas se rendre compte des crash des Qa

[chrisalex]

hello @Lazer

 

je rencontre un petit souci non génant avec ton super Quickapp :

plus d'infos sur la visu :

cependant il continue à fonctionner correctment en cas de défaillance via ton autre quickApp Jpi ou mail

 

merci de ton avis

 

PS : je suis passé en version 5.161.15  .... est ce dû à cela ????
 

Modifié le 29 août 2024 par chrisalex

[Lazer]

C'est pas la nouvelle visu des QA ?
Je n'ai pas fait la mise à jour, mais de ce que j'ai compris tu as une case à cocher sur tous les QA pour revenir à l'affichage normal.

[chrisalex]

j'y avais pensé mais non pas de changement on activant/desactivant la nouvelle visu.

voici ce que ça donne et ça semble ok :

mais en activant la visu plus rien :

du coup j'ai trouvé la soluce e recreant les label à l'identique et là c'est ok .... étrange :

 

[Lazer]

Hum.... bizarre.... bug lors de la mise à jour ?

 

Attention aux Betas !

[henri-allauch]

Le 24/03/2024 à 11:59, henri-allauch a dit :

Juste pour info

C'est la première fois que je vois cracher ce QA depuis plusieurs années.

 

Eh bien maintenant, plus d'un an après:  je peux dire c'est la deuxième fois 

 

21/09/2025 00:07:55;380769;error;QUICKAPP29;"QuickApp crashed"
21/09/2025 00:07:55;380770;error;QUICKAPP29;"Unknown error occurred: LuaEnvironment: opt toolchains aarch64-buildroot-linux-gnu_sdk-buildroot aarch64-buildroot-linux-gnu sysroot usavhttp impl http_stream.ipp:2312: void avhttp::http_stream::handle_skip_crlf(const MutableBufferSequence&, Handler, boost::shared_array<char>, const boost::system::error_code&, std::size_t) [with MutableBufferSequence = boost::asio::mutable_buffers_1; Handler = boost::function<void(boost::system::error_code, long unsigned int)>; std::size_t = long unsigned int]: Assertion  failed."
21/09/2025 00:08:14;380790;trace;QA_NETWORK MONITOR_29;" - *** QuickApp NETWORK MONITOR - MyInit V: 2.12 - Initialisation après temporisation de 14 secondes *** -"

 

Mais sans conséquences Le chien de garde à fait son boulot 🤣

[jojo]

salut @Lazer,

J'ai ENFIN implémenté ce QA, et du coup (comme d'hab), j'ai des commentaires :

je reçois des notifs quand man NAS est down (ok !) à intervalle défini dans le tableau de config avec le paramètre "interval =" (ok !). Ce que je souhaiterais, c'est avoir une notif quand il est down, une autre quand il est à nouveau up, et pas des notifs à chaque check. J'ai essayé ceci

{name = "SynoCam", address = "192.168.1xxx" , port = 5000, protocol = "http" , timeout =  5, url = "/", retcode = 200, retry = 1, interval = 1, notification = {"email"}, vg = "Net_SynoCam", conditions = { vg = "Net_SynoCam" , operator = "!=", value = "0"}}, 

mais quand mon NAS revient à lui, plus de check.

Avec une "bonne" config pourrai-je répondre (en partie) à ma question ? ?

Merci

[henri-allauch]

Le 29/06/2020 à 19:33, Lazer a dit :

vg : facultatif : string : nom facultatif d'une variable globale à incrémenter, celle-ci sera automatiquement créée si nécessaire. Elle est remise à 0 dès que l'appareil surveillé est de nouveau disponible.

 

C'est peut être une solution pour réaliser ton besoin ( je ne sais pas je n'utilise pas de VG)

[jojo]

en fait je n'avais pas vu ta réponse, mais voici la config que j'ai implémentée pour ne recevoir de notif que la première fois

{name = "SynoCam", address = "192.168.1.xxx" , port = 5000, protocol = "http" , timeout =  5, url = "/", retcode = 200, retry = 1, interval = 1, notification = {"email"}, conditions = { vg = "Net_SynoCam" , operator = "!=", value = "0"}}, 
{name = "SynoCam", address = "192.168.1.xxx" , port = 5000, protocol = "http" , timeout =  5, url = "/", retcode = 200, retry = 1, interval = 1, notification = nil, vg = "Net_SynoCam"}, 

pour une notif à fréquence régulière (24h) ce sera avec GEA.

Idem pour le retour disponible

[henri-allauch]

Je pensais une vg mise à jour par le qa qui incrémente à chaque chech si nas est off  quand le nas redeviens on la vg est mise à 0 par le qa 

 

Il suffit ensuite un qa qui teste les changement d'état de la vg et qui fasse une notif au passage à 0

 

C'est compliqué mais si tu as ta solution avec ta config et gea c'est mieux

Modifié le 21 septembre par henri-allauch

[jojo]

oui et ma config fait exactement ce que tu as décrit

[Lazer]

Je pense que tu peux le faire avec 1 seule ligne de config dans Network Monitor (qui va incrémenter la VG et la remettre à 0).
Et dans GEA, avec 2 règles, dont la première se déclenche dès que la VG est supérieure à 0, et l'autre lorsque la VG est égale à 0.

 

[jojo]

oui, mais alors je dépends de 2 QA pour être notifié si mon équipement est HS. Autant diminuer les dépendances non indispensables.

[Lazer]

Oui effectivement.

Bon après Network Monitor n'a pas été conçu pour signaler l'allumage ou l'extinction d'un appareil, mais si tu as réussi à t'en sortir ainsi, alors c'est top.

[jojo]

J'utiliserai GEA en plus, mais uniquement pour détecter le retour à la vie (= pour me signaler les miracles ???) de l'appareil.