Rédaction le 18/12/2018
Mise à jour le 18/05/2019
Mise à jour le 27/07/2019

Cet article couvre le besoin de savoir que tout va bien ou plutôt l’inverse ! Il est particulièrement adapté pour surveiller :

• une installation à base de capteurs Xiaomi sur batterie,
• des niveaux de batterie (même si Jeedom fait ça nativement – relire l’article concerné Onglet Configuration/Equipements),
• la stabilité du réseau,
• le monitoring de charge CPU, RAM etc de vos machines virtuelles ou non,
• vos antennes Bluetooth à base d’antennes Raspberry (voir l’article dédié – machine virtuelle ou Raspberry),
• Jeedom et ses plugins compatibles.

Et tout cela avec :

• des notifications sur conditions intelligentes (trop de notifications = Pierre et le Loup) ;
• avec des designs adaptés (widgets que vous allez découvrir !).

Pré-requis :

• Jeedom et quelques plugins à savoir …
• Virtuel ;
• Widget ;
• Networks ou Ping (je le préfère) ;
• Monitoring ;
• Un de notifications – Telegram dans mon cas ;
• BLEA si vous utilisez des antennes Bluetooth.

Surveillance des batteries – widget :

Jeedom permet de voir le niveau des batteries d’un coup d’œil. Pour rappel, il faut aller dans le menu Analyse / Équipements :

Maintenant, si vous souhaitez présenter cela dans un widget soit par batterie unitaire ; soit par regroupement (un minimum de plusieurs capteurs par exemple permet de vous indiquer qu’au moins un capteur requiert votre attention) :

• Ouvrez le plugin Widget ;
• Dans le market, recherchez le terme “batterie” ;
• Installez le widget de la catégorie “Autre” nommé dashboard.info.numeric.Batterie_Led en cliquant dessus puis “Installer Stable” ;
• Son principe 6 types de LED : rouge clignotant, rouge fixe, vert fixe, bleue – de 0 à 100 sur 4 tranches donc !

Le code parle de lui-même avec les 4 if et les conditions de batterie. Vous pouvez d’ailleurs les modifier si cela ne vous convient pas :

<div style="width:90px;min-height:40px;" class="cmd #history# tooltips cmd-widget" data-type="info" data-subtype="numeric" data-cmd_id="#id#" title="Batterie #name# #state#%">
     <center style="margin: 3px;">
       <span class='cmdName' style="font-weight: bold;font-size : 12px;#hideCmdName#">#name_display#</span></br>
       <span  style="font-size: 12px;font-weight: bold;" id="iconCmd#id#"></span>
   </center>
   <script>
  		var temp;
     	/* calcul du pourcentage de charge par rapport à la valeur max*/
     	temp = ( #state# * 100 ) / #maxValue#; 
     	temp = temp.toFixed(0); // On arrondit;
    
        if (temp > 75 && temp <= 100) {  //piles pleines
          $('#iconCmd#id#').append('<img style="display: block;" src="/plugins/widget/core/template/dashboard/cmd.info.numeric.Batterie_Led/Led_bleue.png" width="15"/>');
        }
        if (temp > 20 && temp <= 75) {
          $('#iconCmd#id#').append('<img style="display: block;" src="/plugins/widget/core/template/dashboard/cmd.info.numeric.Batterie_Led/Led_verte.png" width="15"/>');
      }
        if (temp > 0 && temp <= 20) {
            $('#iconCmd#id#').append('<img style="display: block;" src="/plugins/widget/core/template/dashboard/cmd.info.numeric.Batterie_Led/Led_rouge.png" width="15"/>');

      }
        if (temp == 0) {//piles vides
            $('#iconCmd#id#').append('<img style="display: block;" src="/plugins/widget/core/template/dashboard/cmd.info.numeric.Batterie_Led/LedRougeVide.gif" width="15"/>');
			
      }
    </script>
</div>

Là encore, comme pour les interrupteurs, je vous conseille de créer un virtuel de mise en forme de vos batteries. Plus simple en cas de changement de capteurs par exemple et de lui appliquer ce widget (engrenage, affichage, batterie_led) :

Vous pouvez aussi calculer le minimum de plusieurs capteurs pour ne remonter qu’un niveau de batterie global :

Ce qui permet dans un design de positionner par commande (bouton droit / Ajouter une commande) chaque batterie pour avoir son état. Masquez le titre dans les propriétés (bouton engrenage ou propriétés avancées) de la commande sur Design si vous souhaitez le mettre en forme de manière séparée :

Premier point bouclé ! Pratique et simple de lecture, vous en convenez ?

Surveillance des capteurs – notifications :

Jeedom permet d’être notifié en cas d’un niveau de batterie trop bas – warning ou danger. Pour rappel, cela se passe dans le menu Configuration :

Onglet Équipements :

Puis dans l’onglet Logs, pensez à indiquer le moyen de notifications et si vous souhaitez un message dans le centre de messages de Jeedom. Ici ce sera Telegram encore et toujours !

Notez que vous pouvez régler une valeur par capteur si vous le souhaitez dans un cas plus précis. Directement sur l’information “batterie” du capteur – Onglet Alertes de l’engrenage de l’information. Par exemple, les batteries de mes éléments JPI n’ont pas les mêmes niveaux :

Il vient donc écraser le réglage général dans le cas de CE capteur

On est fortement dépendant de la qualité de la pile et je ne vous conseille que des piles de marque distribuée depuis Amazon. Personnellement, j’ai assez perdu de temps avec les piles de marque (contre-faite) sur Aliexpress ou autre. Oubliez les Varta, Maxwell dont la qualité de fabrication n’est qu’un nom et non plus gage de qualité ! Privilégiez des Energizer, Duracell, Panasonic en lot pour quelques piles d’avance. Rien de pire que d’avoir un capteur de température HS sans pile et que vous devez gérer votre chauffage…

Un exemple concret : un capteur Xiaomi ou un NUT Finder2 avec une pile de mauvaise qualité peut faire un mois ; avec une pile de qualité 18 mois ! D’autant plus visible pour les capteurs de température qui sont dans les frigos que nous avons.

Mon retour d’expérience sur les piles …

Mon installation se base sur des CR123A, CR2032, CR2450, CR1632 (capteurs Xiaomi, incendie Honeywell, télécommandes DIO …)

Télécommande DIO, capteur de température, pression, humidité Xiaomi Aquara – CR2032 par 2, 4 ou 12 :

Piles bouton au lithium Energizer 2032, pack de 2

Piles bouton au lithium Energizer 2032, pack de 4

12 x Energizer CR2032 Coin Lithium 3V Battery Batteries for Watches Torches Keys

Capteur de porte ou fenêtre Xiaomi Aquara CR1632 par 2 ou 4 (plus difficile d’en trouver par 8 ou 16 de qualité, nous ne sommes pas sur la même quantité produite dans le monde) :

ENERGIZER Cr1632 DI1632 Lot de 2 piles boutons au lithium pour clés de voiture 3 V

Panasonic CR1632 3 V Batterie au Lithium Lot de 4 Batterie

Capteur de mouvement Xiaomi Aquara – CR2450 :

LOT DE 2 PILES ENERGIZER CR2450 – 1 BLISTER DE 2 – LITHIUM 3V

LOT DE 6 PILES ENERGIZER CR2450 – 3 BLISTER DE 2 – LITHIUM 3V

Energizer CR2450 DL2450 Lot de 5 Piles Bouton 3 V au Lithium

Capteur incendie fumée Honeywell Xiaomi Aquara – CR123A :

Piles Energizer Lithium Photo 123, pack de 2

Olight® 4 Piles Batteries CR123A Jetable Piles Lithium Non-rechargeable 3V 1600mAh, 4 Pièces

Panasonic CR 123 A Pile au lithium ( 3 V , paquet de 10 )

Bon OK, Jeedom le fait … sauf que j’ai été confronté à des capteurs dont la pile s’arrête “nette” (d’où l’importance d’une pile de qualité) mais il existe toujours des cas “technologiques” de batteries où il peut y avoir un arrêt (utilisation pour la surveillance de frigos ou extérieur) !

Note : Il semblerait que suivant les utilisateurs, le scénario ne convienne pas mais pour moi :

• il surveille tous mes capteurs Xiaomi – Aqara (plus de 60 !) ;
• je n’ai aucun problème de Batterie en b minuscule comme j’ai pu lire que ce soit avec des capteurs Aqara, Xiaomi ou autre, le script les détecte ;
• je l’utilise pour mes :
  • capteurs ouvrants génération 1 Xiaomi ;
  • capteurs température génération 1 Xiaomi ;
  • capteurs température génération 2 Aqara ;
  • interrupteurs Xiaomi ronds ;
  • capteurs de vibration Aqara ;
  • détecteur d’eau Xiaomi ;
  • détecteur gaz/incendie Honeywell ;
  • mouvement Aqara (avec luminosité) ou Xiaomi.

Là encore, un autre cas : plus de remontée d’un capteur car il est dans un état “planté”. Pour cela, un scénario qui tournera toutes les Xh soit 0 */X * * * (à vous d’adapter dans mon cas X=12) nous notifiera si un capteur à batterie n’a pas remonté ses informations. Je sépare le code à mettre dans un bloc “code” puis le traitement dans le scénario :

• si le capteur n’a pas remonté d’informations pendant 12h ;
• le scénario recherche tous les capteurs avec la commande nommée “Batterie” ;
• il tient compte d’une liste d’exclusion ;
• et compare la date de dernière collecte d’une donnée ; son écart par rapport au max autorisé ;
• liste les capteurs en défaut.

$maxTime = 43200; // temps en secondes - 12h maximum

$scenario->setLog("Temps : " . $maxTime);

$batterie = "Batterie"; // Nom de la commande à rechercher
$excludeEq = array(); // Liste des équipements à ignorer (qui contiennent la commande "$batterie")

$errEqLogics = array();

$_format = '%Y-%m-%d %H:%M:%S';

$eqLogics = eqLogic::all();
$scenario->setLog('Début monitoring');

$scenario->setData('monitor', '');

foreach($eqLogics as $eqLogic)
{
  if ($excludeEq[$eqLogic->getHumanName()] == 1){
    $scenario->setLog( '-- Equipement ' . $eqLogic->getHumanName() . ' ignoré');
    continue;
  }
  
  try{
    if (isset($batterie)){
      	// si la commande n'existe pas, une exception est levée
    	$cmd = cmd::byString('#' . $eqLogic->getHumanName() . '['. $batterie .']#');
    }
    
    $scenario->setLog( '-- Equipement ' . $eqLogic->getHumanName());
    
    $allCmds = $eqLogic->getCmd();
    //$maxDate = date($_format, "1970-1-1 00:00:00");
    $maxDate = date($_format, "1970-1-1 00:00:00");
    if (count($allCmds) > 0)
    {
      foreach($allCmds as $cmd)
      {  
          $cmd->execCmd();
          $collectDate = $cmd->getCollectDate();
          // getCollectDate getValueDate
          $scenario->setLog( 'Commande ' . $cmd->getHumanName() . ' - ' . $collectDate);

          //$maxDate = max($maxDate, strtotime($collectDate));
          $maxDate = max($maxDate, strtotime($collectDate));

      }
      $scenario->setLog( 'Date max ' . date('c', $maxDate));
      $elapsedTime = time() - $maxDate;
      
      if ($elapsedTime > $maxTime){
        // -- /!\alert
        $errEqLogics[] = $eqLogic->getHumanName();
      }
    }
    
  }catch (Exception $e)
  {
    // pas de commande
  }
  
}

  $scenario->setData('monitor', implode(",", $errEqLogics));
// log fin de traitement
$scenario->setLog( 'fin monitoring');

EDIT du 18/05/2019 : Je vous engage à lire les commentaires de cet article. Il y a des modifications proposées par les lecteurs du blog. Pour ma part, la version actuelle pour mon installation à base de capteurs Xiaomi, cela fait parfaitement le travail. Mais suivant ce que vous avez comme capteurs, il faut soit les exclure – soit vous aidez des commentaires ! Pour ma part, j’ai simplement exclu les NUTs 3 (les mini, vous pouvez le faire, voir le forum Jeedom) qui ne remontent pas leurs batteries.

$excludeEq = array("[Capteurs et Actionneurs][Nut X]" => 1,"[Capteurs et Actionneurs][Nut Find Y]" => 1,"[Capteurs et Actionneurs][Nut Find Z]" => 1,"[Capteurs et Actionneurs][Nut Find A]" => 1,"[Capteurs et Actionneurs][Nut Find B]" => 1,"[Capteurs et Actionneurs][Nut C]" => 1,"[Capteurs et Actionneurs][Nut D]" => 1,"[Capteurs et Actionneurs][Nut ZA]" => 1); // Liste des équipements à ignorer (qui contiennent la commande "$batterie")

• cette liste de capteurs en défaut doit être vide ;
• si ce n’est pas le cas alors on bascule un interrupteur virtuel “Défaut” ;
• on notifie alors du défaut en affichant les capteurs à problème ;
• sinon on bascule l’interrupteur en OK ;
• on notifie au premier basculement ;
• notez la condition de non-répétition pour ne pas répéter toujours le ou les mêmes capteurs en défaut systématiquement (de même en OK).

L’interrupteur virtuel est “on ne peut plus simple” :

• de type binaire ;
• une commande ON ;
• une commande OFF ;
• avec un widget defaillance très inspiré du précédent, dont voici le code à appliquer à l’information Défaillance :

<div style="padding:0;width:40px;min-height:20px;" class="cmd #history# tooltips cmd-widget container-fluid" data-type="info" data-subtype="binary" data-cmd_id="#id#" data-cmd_uid="#uid#" title="#collectDate#">
	<div class="row">
	    <div class="center-block col-xs-12 iconCmd#uid#"></div>
	</div>
<!-- Ne Pas Supprimer -->
	<script class="createWidgetInfo" type="text/javascript">//<![CDATA[{"type":"1","version":"1","image1":"Led_rouge.gif","image2":"Led_bleue.png"}]]></script>
<!-- Ne Pas Supprimer -->
	<script>
		jeedom.cmd.update['#id#'] = function(_options){
			$(".iconCmd#uid#").empty();
			if (parseInt(_options.display_value) == 1) {
				$(".iconCmd#uid#").append('<img src="/plugins/widget/core/template/dashboard/cmd.info.numeric.Batterie_Led/LedRougeVide.gif" width="15"/>');
			} else {
				$(".iconCmd#uid#").append('<img src="/plugins/widget/core/template/dashboard/cmd.info.numeric.Batterie_Led/Led_verte.png"  width="15"/>');
			}
			$('.cmd[data-cmd_id=#id#]').attr('title','Valeur du '+_options.valueDate+', collectée le '+_options.collectDate);
		}
		jeedom.cmd.update['#id#']({display_value:'#state#',valueDate:'#valueDate#',collectDate:'#collectDate#',alertLevel:'#alertLevel#'});
	</script>
</div>

Qui vous donnera ça :

J’ai aussi fait le choix d’ajouter un bouton “d’action” qui relance le scénario en cas de remplacement d’une batterie par exemple pour éviter 6h entre deux scénarios :

Là encore, un interrupteur avec une information Test binaire qui revient à 0 après 1 minute et une commande Check (manu) qui la passe à 1.

Une action après sur la commande après exécution de la commande – onglet Configuration de l’engrenage de la commande “Check (manu)” lancera le scénario précédent :

Vous voilà donc avec :

• une capacité de visualisation simple du niveau de vos batteries ;
• en auto (toutes les X heures), en manuel depuis vos designs par exemple ;
• une capacité d’être alerté en cas de défaillance d’un capteur ou un niveau de batterie trop bas.

Surveillance du réseau : widget et notifications

Comme je l’ai expliqué dans l’article de l’architecture de réseau, la stabilité d’un réseau domotique (et informatique) permet de garantir une solution domotique fiable et établie dans le temps.

Pour établir cette stabilité, j’ai construit différents indicateurs par Jeedom notamment que je vais vous partager. Hors Jeedom, je me suis appuyé sur JPI pour surveiller mes équipements “sensibles”, voir l’article concerné.

Je vous recommande d’utiliser l’excellent plugin “ping” et non le plugin Networks pas assez fiable sur le type de ping réalisé. Pour cela, il faut passer par un AlternativeMarket pour Jeedom qui vous donnera accès à des plugins supplémentaires.

Prenez le temps de vous informer sur ce que représente cet Alternative Market. En résumé, Jeedom a sa politique, vision ; NextDom la sienne et comme Jeedom est open-source, il est donc modifiable et améliorable selon différents points de vue. Je n’entre pas dans ce débat car je suis utilisateur.

Pour installer ce market alternatif, cliquez ici et suivez la procédure. N’attendez aucun support de ma part pour cela, vous devez comprendre ce que vous faites à minima et vous faire votre opinion.

J’ai donc ensuite installé le plugin PING pour pouvoir utiliser différents types de ping.

https://fr.wikipedia.org/wiki/Ping_(logiciel)

En gros, c’est tu es là ? Oui je suis là ou non et j’ai mis ce temps pour te répondre…

Je vous recommande de lire cet article pour savoir ce qu’est le ping …

Dans la console ou votre client SSH connecté à la machine virtuelle Jeedom, pensez à suivre le guide d’installation du plugin pour que vous puissiez faire du ping avec les bons droits. Si vous avez suivi l’article d’installation de Jeedom, vous n’avez pas à le faire…

Ensuite, il vous faut ajouter les équipements à surveiller, long et fastidieux, mais à la fin le résultat est là ;). Pour ma part près de 30 équipements à surveiller et voici le type de ping que je vous recommande d’utiliser :

• Icmp : Tablettes Android (JPI ou non), interfaces réseau d’un amplificateur audio, caméras Wanscam, caméras Xiaomi, Doorbird, NAS, machines virtuelles, Raspberry, Routeurs
• Arp : Hub Harmony, répéteurs ou modules CPL, téléphones Android

Il y a des recommandations parfois différentes, mais je suis forcé de constater que dans cette utilisation, j’ai très peu de faux négatifs ou l’inverse…

Pour ma part, j’ai masqué le délai dans la surveillance de l’équipement pour éviter d’avoir trop d’informations.

Avant de savoir si un équipement est “tombé” depuis trop de temps, on utilise la possibilité de générer une action sur conditions. Pour cela, cliquez à chaque fois sur Propriétés Avancées (engrenage) dans la colonne Actions de l’information “Etat” de vos équipements :

Dans mon cas (partout), j’historise la donnée pendant 7 jours (suffisant à mes yeux) pour savoir ce qui s’est passé sur l’équipement pendant 1 semaine. Puis si l’équipement n’est pas joignable pendant 15 minutes, je génère une alerte par Telegram :

Avant d’avoir une information de même niveau que le niveau de batterie, j’ai ajouté comme d’habitude des virtuels pour mettre en forme ce “ping”. Un virtuel de “ping global” dans lequel j’ai plusieurs informations où je remonte l’état de chaque équipement précédent :

Comme précédemment, appliquez-y un widget que j’ai construit depuis le widget précédent (de batterie), mais ici il sera de type dashboard/information/binaire. Pensez à inverser vos informations de ce virtuel :

<div style="padding:0;width:40px;min-height:20px;" class="cmd #history# tooltips cmd-widget container-fluid" data-type="info" data-subtype="binary" data-cmd_id="#id#" data-cmd_uid="#uid#" title="#collectDate#">
	<div class="row">
	    <div class="center-block col-xs-12 iconCmd#uid#"></div>
	</div>
<!-- Ne Pas Supprimer -->
	<script class="createWidgetInfo" type="text/javascript">//<![CDATA[{"type":"1","version":"1","image1":"Led_rouge.gif","image2":"Led_bleue.png"}]]></script>
<!-- Ne Pas Supprimer -->
	<script>
		jeedom.cmd.update['#id#'] = function(_options){
			$(".iconCmd#uid#").empty();
			if (parseInt(_options.display_value) == 1) {
				$(".iconCmd#uid#").append('<img src="/plugins/widget/core/template/dashboard/cmd.info.numeric.Batterie_Led/LedRougeVide.gif" width="15"/>');
			} else {
				$(".iconCmd#uid#").append('<img src="/plugins/widget/core/template/dashboard/cmd.info.numeric.Batterie_Led/Led_verte.png"  width="15"/>');
			}
			$('.cmd[data-cmd_id=#id#]').attr('title','Valeur du '+_options.valueDate+', collectée le '+_options.collectDate);
		}
		jeedom.cmd.update['#id#']({display_value:'#state#',valueDate:'#valueDate#',collectDate:'#collectDate#',alertLevel:'#alertLevel#'});
	</script>
</div>

En suivant la même méthode que précédemment, vous pouvez donc ajouter des “commandes” unitaires dans votre design pour suivre si l’équipement est connecté ou “non accessible”.

De même, vous pouvez grouper (comme le calcul du minimum pour les batteries) avec la fonction AND pour savoir si un des équipements groupés est KO. Là encore, un virtuel de mise en forme et une équation à écrire…

Ce qui me donne une surveillance réseau “aisée” pour vérifier :

• les agrégateurs : nodemcu, raspberry ;
• les caméras : Wanscan, Xiaomi, Doorbird ;
• les interfaces : IHM JPI tablettes domotiques, téléphone JPI ;
• les passerelles : Hub Harmony, passerelles Xiaomi ;
• le réseau : CPL, routeurs ;
• les machines virtuelles …

Petit rappel, j’utilise la vue résumé pour savoir le nom d’équipements connectés … Pour cela, rendez-vous dans Configuration / Onglet Résumés et j’y ajoute (bouton +) un élément ping qui est une somme (de 1…) :

Ensuite configurez où vous souhaitez que vos équipements remontent. Dans mon cas, toute la surveillance réseau est un objet “Réseau” qui a comme père “Domotique”. J’ai indiqué que le résumé de cet objet remontera dans le résumé global :

Ce qui vous donnera ça :

Surveillance des démons JEEDOUINO – Raspberry

Ajout du 18/05/2019 : Si vous utilisez Jeedouino, vous avez probablement des démons. J’ai remarqué que par moment (très rare quand même) les démons sont NOK … Pour surveiller cela… un petit scénario !

Un scénario programmé toutes les minutes :

Passez par le démon Jeedouino et relevez les capteurs, états que vous souhaitez surveiller. Par exemple, j’ai une Raspberry dans le garage qui remonte la consommation (pulse) de différents compteurs dans le tableau électrique.

Vous aurez donc ici :

• Etat_Pin_29
• 36_cpt_piscine
• 37_cpt_pv
• etc

Et construisez la liste des informations que vous souhaitez surveiller avec l’objet, identifiant, information. Chez moi, mes PI Jeedouino sont dans l’objet Agrégateurs.

• “#[Agrégateurs][PI-GARAGE][Etat_Pin_29]#”,
• “#[Agrégateurs][PI-GARAGE][36_cpt_piscine]#”,
• “#[Agrégateurs][PI-GARAGE][37_cpt_pv]#”,
• “#[Agrégateurs][PI-GARAGE][38_cpt_ecs]#”,
• “#[Agrégateurs][PI-GARAGE][40_cpt_clim]#”,

Procédez de la même manière pour vos autres démons et éléments Jeedouino.

Merci à Winhex pour son aide et voici le scénario de surveillance qui créera les variables adaptées à vos démons (ce seront les vôtres !). Les miennes sont données à titre d’exemple. Vous pouvez comprendre dans le code le format NOMDEMON-LastCom pour la variable donnera chez moi PI-GARAGE-LastCom.

Je traduis la variable en minute ou heure…

$equipements = array("#[Agrégateurs][PI-CHAUFFEEAU][35_ds18b20]#",
                     "#[Agrégateurs][PI-GARAGE][Etat_Pin_29]#",
                     "#[Agrégateurs][PI-GARAGE][36_cpt_piscine]#",
                     "#[Agrégateurs][PI-GARAGE][37_cpt_pv]#",
                     "#[Agrégateurs][PI-GARAGE][38_cpt_ecs]#",
                     "#[Agrégateurs][PI-GARAGE][40_cpt_clim]#",
                     "#[Agrégateurs][PI-PISCINE][7_ds18b20]#",
                     "#[Agrégateurs][PI-PISCINE][11_ds18b20]#",
                     "#[Agrégateurs][PI-PISCINE][12_input_pullup]#",
                     "#[Agrégateurs][PI-PISCINE][13_ds18b20]#",
                     "#[Agrégateurs][PI-PORTAIL][35_input_pullup]#",
					 "#[Agrégateurs][PI-PORTAIL][37_input_pullup]#",
                     "#[Agrégateurs][PI-PORTAIL][7_compteur_pullup]#",
                     "#[Agrégateurs][PI-PORTAIL][33_input_pullup]#");

$maintenant = (new DateTime(date("Y-m-d H:i:s")));
$valeurfin = ($maintenant->format('Y-m-d H:i:s'));
$valeurfin2 = ($maintenant->getTimestamp());

$scenario->setLog("maintenant : $valeurfin timestamp : $valeurfin2");

foreach ($equipements as $equipement) {
	$cmd = cmd::byString($equipement);
	$idEquipt = $cmd->getEqLogic_id();

	$equipt=eqLogic::byId($idEquipt);
  
	$nomEquipement = $equipt->getName();
	$valeurdbt= $equipt->getStatus('lastCommunication');
  
// 1er methode différence delta
	$delta = gmdate("H:i:s",strtotime($valeurfin) - strtotime($valeurdbt));
  
// 2eme methode difference timestamp
  	$temp_difftime = ($valeurfin2 - (new DateTime($valeurdbt))->getTimestamp());
  	$scenario->setLog("-----------------------------------------------------");
	$scenario->setLog("Nom du device : $nomEquipement id : $idEquipt");
	$scenario->setLog("dernière communication : $valeurdbt différence : $delta secondes : $temp_difftime");
  $scenario->setData($nomEquipement."_LastCom", $temp_difftime);
  }

La principale limitation est que si vous avez des capteurs “peu verbeux”, le temps de la dernière communication peut être long ! J’en ai qui remonte à 5 minutes, d’autres toutes les 12 heures …

J’utilise ensuite le même principe que le chapitre d’après (BLEA). Je traduis les variables dans des informations de type binaire :

Vous connaissez déjà l’astuce, je préviens par Telegram sur la propriété avancée de l’information binaire :

Surveillance des antennes BLEA – Raspberry Bluetooth

Voir l’article dédié pour leur mise en place !

Mais le démon sur la Raspberry peut s’avérer capricieux ! Oui … et comment s’assurer qu’il est bien en ligne et qu’il remonte bien les données captées à Jeedom et qu’il va redémarrer tout seul ? Depuis ce printemps, l’auteur du plugin a mis en place une gestion automatique du démon. Mais comme j’aime savoir si c’est tombé et donc reparti… je préfère ma méthode :). A vous !

Ajoutons un scénario qui tourne toutes les minutes (* * * * *) avec ce code :

$remotes = blea_remote::all();
foreach ($remotes as $remote) {
  $last = $remote->getConfiguration('lastupdate','0');
  $_key = "BLEA_".$remote->getRemoteName()."_state";
  if ($last == '0' or time() - strtotime($last)>65){
    $scenario->setData($_key, 0);
  } else {
    $scenario->setData($_key, 1);
  }
}

Depuis la mise à jour de BLEA du fin Juillet 2019, il faut remplacer la fonction getConfiguration par getCache ce qui donnera :

$last = $remote->getCache(‘lastupdate’,’0′);

Ce code va créer des variables pour chaque antenne et leur état 0 ou 1 (KO ou OK…). Exécutez votre scénario et cliquez sur “variables” pour noter vos variables :

Il vous suffit de mettre en forme ces variables par un …. VIRTUEL (si tu n’as pas répondu juste tu relis 30 fois l’article :D) :

Et d’indiquer vos variables par variable(nomdelavariable) et d’y appliquer le widget binaire vu dans le sous-chapitre précédent (dashboard/info/binaire) :

Mais comme je souhaite avoir l’information que tout va bien, je vais remonter ce binaire avec le ping pour chaque antenne. Pour cela, j’ai simplement modifié l’information initiale du ping par un ET du ping et de l’état du démon. A faire pour chaque antenne :

Pour savoir si j’ai un problème de relance, j’ai ajouté une notification par Telegram sur chaque état du démon en cas de KO (0) pendant plus de 5 minutes, comme pour le ping à 15 minutes :

Je le redis différemment, ici cette notification aura lieu si la relance automatique que nous n’avons pas mis en place encore – n’a pas eu lieu.

Ajoutez donc un scénario provoqué qui relancera tous les démons KO avec ce code :

$remotes = blea_remote::all();
foreach ($remotes as $remote) {
  $last = $remote->getConfiguration('lastupdate','0');
  $_remoteId = $remote->getId(); 
  if ($last == '0' or time() - strtotime($last)>65){
    $scenario->setLog('Antenne BLEA : '. $remote->getRemoteName() . ' , état KO, redémarrage du démon');
    message::add('networks','Antenne BLEA : '. $remote->getRemoteName() . ' , état KO, redémarrage du démon');
    blea::launchremote($_remoteId);	  
  } else {
    $scenario->setLog('Antenne BLEA : '. $remote->getRemoteName() . ' , état OK');
  }
}

Depuis la mise à jour de BLEA du fin Juillet 2019, il faut remplacer la fonction getConfiguration par getCache ce qui donnera :

$last = $remote->getCache(‘lastupdate’,’0′);

Mais il faut un scénario qui lancera le scénario de “relance” sur 2 modes : provoqué + programmé :

• il se lancera toutes les 5 minutes : */5 * * * *
• et sur chaque information d’état de vos états (le virtuel qui relie les variables d’état du démon)
• et ce scénario – autant de SI/ALORS que d’antennes :
  • si l’état est KO, j’informe et je lance le scénario de relance de démon,
  • j’active la non-répétition pour le faire qu’une fois en cas de KO ou OK,
  • j’informe ainsi que c’est OK dès le premier passage à 1.

Et voilà, on arrive au bout ! non…

Jeedom…

Pour savoir si tout va bien du côté de Jeedom, utilisons le plugin Jeedom Link. Le principe est de récupérer l’état de santé de Jeedom et de nous informer.

Vous pouvez faire cela pour autant de Jeedom installés que vous avez. Cliquez sur Jeedom Cibles et ajoutez un :

• votre Jeedom Cible, votre VM par exemple ;
• son IP ;
• la clé API – voir l’article suivant si perdu ;
• l’accès à ce Jeedom : interne ;
• Sauvegarder.

Au bout de quelques secondes, votre Jeedom apparaît. Cliquez dessus, activez-le, rendez-le visible et affichez l’état des plugins que vous souhaitez surveiller.

Je passe la partie Virtuel de mise en forme pour Jeedom vu que vous avez compris le principe. Je fais un ET de l’ensemble des plugins :

A cela, j’ai ajouté un scénario qui tourne toutes les heures décalées de 6 minutes (pour moins charger Jeedom soit 6 * * * *) :

Dans le principe :

• on rafraichit l’état de santé de Jeedom,
• on attend quelques secondes,
• on regarde si l’un des démons est KO,
• on informe par SMS+Télégram,
• comme pour le scénario de relance, non-répétition pour éviter des envois incessants en cas de problème et notifications au premier changement d’état.

Le monitoring de vos machines virtuelles et autres équipements CPU/RAM

Ajout de cette partie supplémentaire. Dans le principe, rien de compliqué. Je vous recommande l’utilisation du plugin monitoring qui fait le travail parfaitement.

Cas particulier avant, le NAS – si vous possédez un QNAP. J’ai aidé son auteur pour avoir un widget adéquat dans vos designs. Donc vous pouvez le remercier !

Téléchargez ce plugin par le market, comme habituellement puis lancez-le par le menu Plugins.

Après avoir installé les dépendances (attention ce plugin ne fonctionne pas sur une distribution inférieure à Debian9), ajoutez votre NAS en ayant activé le SNMP et le SSH en local.

Configurez l’IP, l’utilisateur SSH et son mot de passe (habituellement admin etc), le port SSH choisi. Faites de même côté SNMP en “private” en v2.

L’auteur a ajouté une visualisation “couleur” des niveaux de charge. Vous pouvez dans l’onglet commandes choisir ce que vous souhaitez afficher. De même, dans la configuration avancée (engrenage) de votre objet Jeedom correspondant au NAS, vous pouvez choisir la couleur du texte, le fond etc :

Qui me donnera ceci sur mon design :

Pensez que vous pouvez ajouter une notification sur un de ces grandeurs. Par exemple si la température du CPU dépasse 60°C pendant plus de 5 minutes, je souhaite être alerté par Telegram.

Et ajoutez une action si > 60 pendant plus de 5 minutes :

Pour ma part, je ne souhaite pas ce type de notifications, car cela est géré depuis mon NAS QNAP. Et je préfère me rendre indépendant sur cette gestion.

Ensuite pour vos autres équipements : Hyperviseur Proxmox, machines virtuelles, Raspberry etc – c’est pareil mais avec le plugin Monitoring ! Pareil, on l’ajoute, on l’active, on installe les dépendances.

Et là, ajoutez la surveillance de vos machines virtuelles, Raspberry etc. Le principe est le même mais en SSH :

• configurez si la carte réseau à surveiller (trafic, disponibilité),
• la plupart du temps l’équipement est déporté,
• son IP alors,
• le port SSH (22 en général sauf si vous faites des changements),
• le login/mot de passe de l’utilisateur (votre user sudo).

Vous pouvez modifier les seuils de couleurs d’affichage alors que sur le plugin QNAP elles sont déjà réglées. A noter qu’il y a de belles inversions par moment, cela a été remonté plusieurs fois sur le forum mais jamais corrigé hélas ! Voici ma configuration pour une Raspberry qui a 4 cœurs (à régler différemment donc pour un core i7 avec 8 cœurs…) :

Là encore, vous pouvez modifier le fond, texte de votre widget comme pour le plugin précédent. A vous !

Vous voilà avec tout ce qu’il faut pour surveiller, être notifié, relancer vos équipements domotiques et votre installation Jeedom. J’ai mis du temps à mettre celle-ci en place et j’ai agrégé plusieurs techniques à chaque fois. A mes yeux, il ne reste qu’un point, la capacité de remonter l’état des batteries des NUTs Bluetooth (qui est déjà possible pour les mini et 3).

La conclusion de cet article !

Si vous avez aimé cet article, faites-le savoir, partagez-le ! Et n’hésitez pas à me supporter avec un don financier car cela prend du temps de mettre tout cela en forme pour vous 😉 !

Merci à vous !