Aller au contenu
Lazer

Quick App - Network Monitor

Recommended Posts

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?

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

Partager ce message


Lien à poster
Partager sur d’autres sites

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

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

Partager ce message


Lien à poster
Partager sur d’autres sites

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

  • Like 1

Partager ce message


Lien à poster
Partager sur d’autres sites

×