La surveillance de vos équipements domotiques

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 !).
Exemple de design de surveillance de l’installation domotique
En un coup d’œil, voir que tout est bon !

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 :

Pour voir l’état de santé de vos batteries (1)
Super ! mais dans un design ?

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) :

Virtuels de mise en forme des batteries (1)
Virtuels de mise en forme des batteries (2)

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

Virtuel pour le minimum de l’ensemble des capteurs

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 :

Suivi des niveaux de batterie des capteurs sur design (1)
Suivi de l’ensemble des niveaux de batterie des capteurs sur design (2)

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 :

Pour appliquer un niveau “global” de batterie : avertissement/danger (1)

Onglet Équipements :

Pour appliquer un niveau “global” de batterie : avertissement/danger (2)

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 !

Notifications en cas d’avertissement/danger

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 :

Réglage spécifique du niveau de batterie

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 EmilouVincent]" => 1,"[Capteurs et Actionneurs][Nut Find 308]" => 1,"[Capteurs et Actionneurs][Nut Find Benjamin]" => 1,"[Capteurs et Actionneurs][Nut Find Emilie]" => 1,"[Capteurs et Actionneurs][Nut Find Swift]" => 1,"[Capteurs et Actionneurs][Nut Hayabusa]" => 1,"[Capteurs et Actionneurs][Nut MichelFrancoise]" => 1,"[Capteurs et Actionneurs][Nut PapaMaman]" => 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).
Scénario de notifications en cas de panne d’un capteur à batterie

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>
Virtuel de défaillance de capteurs (1)

Qui vous donnera ça :

En design – version information 

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 :

Action pour relance du scénario de vérification des capteurs

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.

Virtuel de relance du scénario de vérification des capteurs

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 :

Action de lancement du scénario de vérification des capteurs

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 …
Ajout du plugin 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…

Onglet configuration, récupération du guide d’installation, détection des bons programmes d’utilisation du ping

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…

Ajoutez vos équipements …

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 :

Ouvrez les propriétés avancées

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 :

Notifications en cas d’équipement injoignable

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 :

Virtuel de mise en forme de surveillance ping des équipements

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”.

Ajoutez ensuite le ping mis en forme de vos équipements

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…

Par exemple, je surveille les 4 connexions de mon NAS avec un seul indicateur

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 …
Surveillance du réseau d’un coup d’oeil

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…) :

Page configuration
Ajout d’un résumé domotique avec le nombre d’équipements connectés

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 :

Je remonte donc le nombre d’équipements dans le résumé “ping”

Ce qui vous donnera ça :

Nombre d’équipements connectés

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 :

Scénario pour la surveillance des démons Jeedouino

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.

Identification des pins sur un démon Jeedouino

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…

Scénario de surveillance JEEDOUINO
$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 :

Surveillance JEEDOUINO
Virtuel de surveillance JEEDOUINO

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

Action si Démon KO plus de 5 minutes au delà des 10 minutes programmées…

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 :

Les variables sont de la forme : BLEA_nomantenne_state

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) :

Virtuel de mise en forme pour avoir l’état des démons

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) :

Les variables reliées

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 :

Modification du ping pour avoir un état global d’une antenne : ping+démon

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 :

Notification Telegram en cas de relance KO

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.
Scénario de pilotage de la relance des démons

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.

Le plugin Jeedom Link

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

Ajout de Jeedom Cible

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.

Surveillance de votre Jeedom par JeedomLink

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 :

Virtuel de mise en forme pour Jeedom
État de santé de Jeedom d’un coup d’oeil …

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 * * * *) :

Scénario de surveillance de Jeedom

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.

Monitoring d’un NAS QNAP

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.

Activation du SNMP v1/v2 sur le QNA
Activation du SSH – choisissez le port ou laissez le port par défaut

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.

Configuration de votre QNAP côté Jeedom

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 :

Configuration du widget QNAP

Qui me donnera ceci sur mon design :

Widget de santé de notre NAS QNAP

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.

Configuration avancée de la commande pour être notifié

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

Ajout d’une notification en cas de dépassement de température

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.

Plugin Monitoring

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).
Configuration d’un élément en monitoring

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…) :

Configuration du monitoring d’une Raspberry

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

Côté design, le monitoring !

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).

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 !

One thought on “La surveillance de vos équipements domotiques

  1. Bonjour,

    Merci pour cet article des plus intéressant. Juste pour info pour le widget batterie led, je penses que vous avez du le modifier, en effet par defaut dans la version stable il n’y a pas l’information sur le nom du virtuel il faut ajouter la ligne suivante

    #name_display#

        1. Je me répond a moi même il faut aller dans la configuration de jeedom et dans résumé pour ajouter soit même une catégorie Ping (je n’avais encore jamais été à cet endroit :p )

  2. Encore un super article

    J’ai tendance à le répéter souvent ici 🙂

    Juste une question: le widget batterie dans le market est de type numeric.
    Il suffit de le dupliquer, changer son nom et son type pour pouvoir l’utiliser en type binaire? Ou y a t il d’autres paramètres à changer dedans? ….. surement mais une tentative de modif d’un autre widget s’est soldé par un échec malgré des heures passées dessus.
    Désolé si la question semble évidente mais je suis un noob dans le design/widget , Je maitrise pas du tout cette partie widgets et leur configuration.

    1. J’ai réussi ! Enfin un widget modifié qui fonctionne!…. après avoir ressorti mes lunettes !!

      Le truc c’est que c’est tellement complet tes articles qu’on passe facilement à coté de la bonne info qui nous manque et qui nous fait tourner en rond. Mais bon c’est ça aussi faire de la domotique!

      1. Sans vouloir te vexer, faut lire… J’ai bien compris que tu n’avais pas lu. Mais je ne peux pas mieux écrire que des articles longs. Enfin je m’efforce… Même si des fois je raccourcis un peu car je me dis que c’est trivial.

        Bonne continuation !

  3. Bonjour.
    Petite question. Dans de scénario de surveillance des capteurs sur batterie pour exclure des équipements il faut les exclures directement dans le code?

  4. Bonjour,
    Très bon article très instructif.
    Par contre, j’ai un soucis.
    Dans le scénario de contrôle de batterie, si l’équipement contient des commandes elles s’exécutent, comment puis-je contourner ce soucis ?

    1. Tu peux passer sur le sujet sur le forum jeedom et poser la question au fournisseur du script d’origine que j’ai modifié légèrement.
      Personnellement je n’inclue pas de commande dans mes capteurs, je passe par un virtuel.

      1. Bonjour,
        Merci pour cet article très intéressant.
        J’ai cherché mais je n’ai pas trouvé de post sur le forum jeedom concernant la portion de code utilisé dans le scénario de contrôle de batterie. Est ce qu’il serait possible d’avoir un lien?
        Je débute sur Jeedom et j’essaye de mettre en place une vérification stricte de tous mes équipements (même ceux sur secteur qui peuvent être débranchés par erreur).
        J’ai des questions/évolutions comme par exemple la prise en compte des modules Xiaomi/Aqara qui ont une propriété “batterie” (avec un b minuscule) au lieu de “Batterie” (avec un B Majuscule) qui font que la version actuelle du script ne les surveille pas.
        Idem sur le fait qu’il doit aussi être possible de surveiller des équipements sans batterie (pour surveiller le débranchement d’un module normalement sur prise électrique).
        Enfin (et pour répondre à Mathieu si je comprend bien sa question) il est possible de ne sélectionner que les commandes de type “Info” via la modification de la ligne :
        $allCmds = $eqLogic->getCmd(‘info’);
        Cela évite ainsi les commandes de type action que la ligne en dessous “$cmd->execCmd();” lance.
        En effet, lors de mes tests j’ai inclus par erreur tous les modules déclarés dans jeedom et le script a lancé toutes les commandes, y compris des commandes de mise à OFF des prises connectés… toute mes prises électriques se sont éteintes.

        Je suis en train de préparer une version élargie, mais je ne sais pas comment la partager.

        1. Bonjour,

          En toute rigueur, il te suffit déjà de changer la propriété en la renommant avec un B majuscule. A mon avis, le développeur du plugin n’a pas du faire attention dans la création des éléments.
          Je vérifierai, j’attends 2 capteurs de vibration pour ma porte de garage.

          Olivier, envoie-moi ton code, je le publierai directement sur le blog pour tout le monde avec ton accord. Tu peux m’écrire sur benj29@jeedom-facile.fr !

          Bonne journée,
          Benjamin

  5. Bonjour,

    Merci pour cet excellent article, je profite des fêtes pour fiabiliser ma supervision.
    Je débute avec le bloc code dans jeedom et je ne comprends pas comment fonctionne l’exclusion.

    J’ai complété l’objet de la manière suivante :
    $excludeEq = array(“[Labo][Bouton clic]”,”[Coin nuit][Smoke Sensor]”); // Liste des équipements à ignorer (qui contiennent la commande “$batterie”)

    Néanmoins l’exclusion ne semble fonctionner qu’à moitié :
    évaluation de la condition : [“[Coin nuit][Smoke Sensor]”!=””] = Vrai

    Pourrais-tu m’éclairer ?

    1. Perso j’ai modifié la ligne qui vérifie si la commande est dans les exclusions.
      Je suis pas super en PHP mais ça marche pour moi
      remplacer : if ($excludeEq[$eqLogic->getHumanName()] == 1){
      en : if (in_array($eqLogic->getHumanName(),$excludeEq)){

        1. Bonjour à vous,

          Super tuto comme d’habitude Benjamin !
          J’ai effectivement dû remplacer la ligne d’exclusion comme damda58 pour ignoré certains de mes équipements.
          Pour info, je suis sous Rpi3 avec jessie.
          😉

      1. Bonjour,

        J’ai effectué aussi ce changement car je voulais ignoré mon Roborock S50 que ce script rend fou :p (oui il lui fait démarrer chaque commande 😀 )

        Avec le test de base en effet il n’était pas ignoré

  6. Merci beaucoup 😉
    Tuto excellent qui m’a permit de monitorer et démarrer automatiquement mes antennes BLEA
    très clair, facile à mettre en place et efficace

  7. Merci encore pour ce superbe Tuto Benjamin. Enfin, plutôt pour cette encyclopédie du monitoring via Jeedom.

    J’ai pris en main l’outil il y a quelques jours maintenant et grâce à toi et à tes articles, mon installation avance à vitesse grand-V !

    Laurent

  8. Merci pour cette article que j’ai pu implémenté en partie pour mon installation.

    Petite question par rapport au monitoring de jeedom. Tu créais un virtuel “Jeedom” avec des “ET” pour les différents demon. Ensuite dans le scenario, pourquoi ne pas utiliser ce virtuel dans le SI au lieu de remettre tous les demons avec de ET comme tu l’as fait?

  9. Salut benj.

    As tu essayé la surveillance des daemons jeedouino sur les rpi?
    J’ai essayé avec le code que tu indique pour les blea en remplaçant jeedouino mais ce n’est pas aussi simple que cela apparement ^^.

    Marmoul

    1. Salut Marmoul,

      Surveiller les démons ? Comment (par code comme pour les démons BLEA je présume ? L’intérêt est faible je trouve, il redémarre automatiquement 4 min après le dernier boot. Je n’ai jamais eu de soucis. J’ai plus un souci sur une PI Wifi (la seule) pour la piscine qui ne reprend jamais son réseau Wifi toute seule en cas de coupure réseau (faut que je regarde). Il faut que je coupe l’électricité et ça repart.

  10. Bonjour Benjamin,

    Merci pour toutes ces informations c’est vraiment super, j’ai fait un bon dans mon avancement 😉
    J’ai une question car j’ai copié pour faire la surveillance des batteries et j’ai des capteurs (Xiaomi Aqara) qui ne remonte pas de mise à jour pendant les 12h. Par contre si j’ouvre la porte l’information est bien remontée. J’ai peut-être raté quelque chose mais je comprends pas pourquoi j’ai pas la mise à jour de batterie si je ne fais pas d’action d’ouverture.

    Merci

    1. La batterie ne remonte que si la valeur change. C’est peut être un effet de bord des capteurs Aqara car j’ai principalement que du V1.
      D’ailleurs un membre s’était proposé de partager son code plus “costaud” et “complet”, malheureusement jamais reçu.

  11. Salut! Tout d’abord toutes mes felicitations pour ton site, c’est une mine d’informations pour mon Jeedom.
    J’ai des capteurs Xiaomi (température hygrométrie pression). Lorsque je vais dans l’onglet analyse / équipement / batteries, tout est vide, aucun équipement n’apparaît… Je n’utilise pas la gateway Xiaomi mais une clé zigbee2mqtt qui fonctionne parfaitement. Les infos de batterie remontent bien dans les widgets, mais rien n’apparaît ici. Est-ce que j’ai raté quelque-chose dans la config de jeedom ?

  12. Re bonjour,

    Benjamin j’ai une petite question quel est l’utilité de lancer chaque commande d’un capteur si c’est seulement pour avoir une information de batterie ?

    C’est par curiosité, car dans mon cas j’ai eu un petit soucis avec mon roborock S50 je croyais qu’il devenait fou :p

    Je l’ai ajouté à l’exclusion et la plus de soucis, mais du coup ça ma posé question sur l’utilité de cela dans le script 🙂

  13. Comme je l’ai expliqué, je n’ai n’y le temps ni les compétences requises pour modifier ce code PHP. Un utilisateur sur ce fil a dit qu’il l’avait fait et allait le partager. On attend encore hélas !
    Pour ma part, il fonctionne parfaitement car j’utilise principalement du Xiaomi.

  14. Bon et bien du coup je me suis permis d’adapter le script pour qu’il n’utilise que les commande contenant le mot Batterie et qu’il évite de lancer chaque commande, si jamais cela peut être utile à d’autre :

    Je l’ai mis dans un paste bin au cas ou, je n’ai rajouté qu’un test rien de bien compliqué, ça semble bien fonctionner (si d’autres veulent tester !), et j’ai également modifier le test pour l’exclusion

    https://pastebin.com/jW8n1q5V

    Bonne journée

    1. Bonjour,
      le site est top bravo à son auteur
      par contre j’ai un soucis justement avec le code de verification des capteurs, j’ai du zwave, une nuki et du xiaomi
      lors de la verification du code a 00h00 le script ouvre ma porte d’entrée j’ai donc mis en exclusion, pareil pour mon aspi xiaomi il réagit à l’exclusion de ce code et ma sirène en zwave ce déclenche 30secondes à minuit , mon thermostat netatmo plante etc…

      est ce que le code modifier par Tarlak permet de résoudre ce problème??

      $batterie = “Batterie”; // Nom de la commande à rechercher
      $excludeEq = array(“[Sécurité][Serrure Porte Entree]” => 1,”[Extérieur][SHAUN]” =>1,”[LabosDeTEST][chuwi]”=> 1,”[Salon][aspirateur Xiaomi]” => 1,”[Local technique][Netatmo Thermostat maison]” =>1, “#[Véranda][Sirene]”=>1); // Liste des équipements à ignorer (qui contiennent la commande “$batterie”)

  15. La fonction d’exclusion s’écrit bien de cette façon :

    $excludeEq = array(“[Capteurs et Actionneurs][X]” => 1,”[Capteurs et Actionneurs][Y]” => 1,”[Capteurs et Actionneurs][Z]” => 1); // Liste des équipements à ignorer (qui contiennent la commande “$batterie”)

  16. Bonjour,

    Très bel article qui donne envie d’aller plus loin dans la domotique.
    Malheureusement, pour avancer je dois résoudre un problème dont je ne trouve pas la solution. Vous n’avez sans doute pas la même approche que moi, mais vos connaissances indiscutables vous permettront peut-être de m’aider si vous le voulez bien.

    J’ai installé PAW et JPI sur mon téléphone Galaxy S3 MINI.
    Je voulais commander la caméra de ma tablette à partir de ma RASPBERRY et de MOTIONEYE, j’ai pu le faire en installant IP Webcam sur la dite tablette.
    Je voudrais maintenant accéder au getBattLevel de ma tablette pour faire un scénario de recharge automatique, malheureusement, bien qu’ayant créé un équipement JPI avec l’adresse de cette tablette, la commande système n’y accède pas et me renvoie 0.
    J’ai mis le port 8085 d’IP Webcam, puis 80, mais je vais dans l’inconnu, je ne vois pas quel autre port mettre.
    Ou alors, pour accéder aux données d’une tablette à partir de mon téléphone ou de mon ordinateur, faut-il charger sur cette tablette une appli comme IP Webcam pour la vidéo ?
    D’avance, merci de prendre le temps de me répondre.

    1. Merci pour vos éloges mais n’en faites pas trop ! Il y a des installations plus avancées que la mienne ;).
      Je m’efforce juste de vulgariser pour que cela soit accessible à tout un chacun.
      Pour accéder à la caméra d’un JPI vous ne pouvez pas le faire simplement.
      Il faut récupérer le flux (vous aurez l’accès au flux pour démarrer/arrêter le flux) dans le menu de JPI.
      https://i.imgur.com/nUZUl6p.jpg

      Et là il faut ajouter cette adresse dans motioneye sous la forme “simple mpjeg webcam”.

      Par contre, je déconseille d’avoir le flux en permanence activé.
      Je n’ai jamais eu quelquechose de stable que ce soit sur un téléphone avec 4 Go de ram (mine de rien !) ou une tablette avec autant de RAM. Alors imaginez sur un S3 mini ou une tablette d’entrée de gamme. PAW plante trop souvent.

      Personnellement, je désactive le démarrage automatique du flux :
      https://i.imgur.com/l1AeEOD.png

      Et je l’active par le plugin JPI depuis Jeedom et je l’arrête à la demande (en cas d’intrusion ou manuellement).
      Commande stop & startstreaming.

      1. Merci pour ces explications mais, indépendamment de la vidéo, pour ce qui est de la communication avec une tablette et la récupération des données, notamment son getBattLevel , avez-vous une idée d’appli à installer sur cette tablette ou d’adresse ou de port à utiliser ?

          1. Bonjour,
            J’ai bien le plugin JPI d’activé. Je parviens également à récupérer les images de la webcam de ma tablette, ce n’est pa là mon souci, par contre, je suis admiratif devant votre tableau “Pour voir l’état de santé de vos batteries ” car c’est là où je bute depuis des semaines.
            En effet, je commande (j’essaie en fait !) PAW et JPI de djul à partir d’un S3 mini.
            Je parviens facilement à connaître le getBattLevel de ce S3 mais je suis incapable d’obtenir celui des autres appareils tels que celui de ma tablette galaxy ou du smartphone de mon épouse.
            Vous avez sans doute résolu ce problème puisque vous arrivez à tester la batterie d’un grand nombre d’appareils.
            C’est la réponse à cette question que je souhaiterais connaître : comment faites-vous pour obtenir le niveau des batteries de vos appareils ?

          2. On ne doit pas se comprendre. Vous me parlez de niveau de batterie de capteurs ou de JPI ? De capteurs, regardez la partie de l’article (certes long) où je récupère le niveau de batterie (xiaomi, rfxcom) que je mets en forme avec un widget spécial. Pour JPI, pareil, dans le même principe. J’ai comme l’impression que vous n’avez pas compris quelque chose dans l’article.

  17. Bonjour Benjamin,

    J’ai acheté et installé des modules CPL TP-LINK TL-PA8015P dont 1 en “tête” de réseau CPL, branché sur une prise libre du tableau électrique.
    Par contre, le plugin Ping ne les détecte pas alors que j’ai récupéré leur MAC address dans l’interface de la box et que j’utilise bien le mode ARP. Est-ce qu’il y a une astuce ?

    fx

    1. Bonjour,

      Non rien de plus. Je viens de vérifier, c’est bien ARP et l’adresse MAC du module.
      Essaie de faire ping sur IP et le port 80 qui est le port web de l’interface de configuration.

      Benjamin

      1. Benjamin,
        Je ne suis pas sûr de bien comprendre. Le module CPL n’a pas d’adresse IP, seulement une adresse MAC donc je ne peux pas faire ce que tu me dis d’essayer. Est-ce que tu pourrais me partager le log en mode DEBUG pour que je vérifie le contenu de la ligne de commande ?
        fx

        1. Je reviens sur ce sujet (même s’il n’est pas essentiel) car je ne comprends pas comment un équipement qui n’a pas d’adresse IP peut répondre à la commande ARP (ce qui est justement le cas des modules CPL)…
          fx

  18. Bonjour Benjamin,

    Il s’agit de JPI. Pour faire très simple, je voudrais contrôler la charge de ma tablette avec le plugin JPI. Dois-je installer PAW et JPI également sur ma tablette ?
    Actuellement, je n’ai fait que remplir l’adresse de cette tablette sur un nouvel équipement du plugin JPI de Jeedom mais cela n’est pas suffisant apparemment !
    J’ai bien lu votre article sur JPI mais je ne trouve pas ces informations dessus.

    1. Désolé, si ce n’est pas clair, mais OUI ! Comment voulez-vous piloter un logiciel (APK) Android depuis un plugin si vous ne l’installez pas ? :).
      Attention, PAW n’est plus disponible sur le market. Il faut l’installer depuis le site du développeur :
      http://paw-android.fun2code.de/
      Quand à JPI, idem faut le télécharger depuis le site de Djul :
      http://rulistaff.free.fr/JPI/fr.djul.JPI-0.93-minAPI15.apk
      Lors de la première installation, l’APK se mettra à jour tout seul (code local).
      Bon réglage !

  19. Très bien, ça me semble plus clair, je vais essayer de mettre en pratique vos informations et vous tiendrai au courant.
    Bonne soirée.

    1. Bonsoir,

      Merci pour vos conseils. Grâce à vous j’ai enfin pu détecter le niveau de batterie de ma tablette. Je vais ainsi pouvoir aller un peu plus loin dans la gestion de ma “domotique” !

      A plus.

  20. Bonjour Benjamin,
    Le plugin Jeelink me remonte en permanence cette erreur : “Attention le plugin Jeedom Link n’a recu de message depuis 5 min”. Poutant le log Jeelink est vide et j’ai l’impression que les infos sont à jour…
    Est-ce que tu as une idée ?
    Cordialement.
    Fx

  21. Bonjour,

    J’ai ajouté quelques améliorations de mon point de vue :

    Ne traiter que les équipements actifs :
    …..
    $allCmds = $eqLogic->getCmd();
    $actifEquipement = $eqLogic->getIsEnable();
    //$scenario->setLog( ‘équipement actif – ‘ . $actifEquipement);
    $maxDate = date($_format, “1970-1-1 00:00:00”);
    if (count($allCmds) > 0 && $actifEquipement == 1 )
    {
    …..

    Ne traiter que les commandes de type info (car sur certain équipement l’exécution de la commande Action me fait des comportements bizarre).
    ….
    foreach($allCmds as $cmd)
    {

    $typeCmd = $cmd->getType();//on récupére le type pour ne pas executer les actions
    //$scenario->setLog( ‘Commande ‘ . $cmd->getHumanName() . ‘ – ‘ . $collectDate);
    //$scenario->setLog( ‘Type – ‘ . $typeCmd);
    if ($typeCmd == “info”){
    $cmd->execCmd();
    $collectDate = $cmd->getCollectDate();
    $maxDate = max($maxDate, strtotime($collectDate));
    }

    }

  22. super article.
    ça a répondu a pas mal de question. et ça en apporte d’autres 😉
    Comment vous ajoutez la partie graphique dans supervision système?
    C’est peut être une question bête.

  23. Salut Benjamin,

    Super boulot !! surtout pour un bidouilleur de base comme moi.
    Petite question, depuis la Maj de pas mal de chose sur jeedom, je n’ai plus les noms qui apparaissaient au dessus des diodes “surveillances blea”, tu saurais ou il faut que je modifie pour de nouveaux avoir des noms visibles….parce que juste les leds vertes ou rouges ça aide pas beaucoup…Merci

  24. Bonjour,
    J’ai l’impression de pédaler dans la semoule !!
    Suite à un crash de carte SD, j’ai dû faire une nouvelle installation de Jeedom. J’ai mis Paw et JPI dernières version sur mon Galaxy S3 mini et un seul plugin : JPI sur Jeedom pour le tester.
    Avant le crash, depuis JPI sur Jeedom, j’accédais facilement et grâce à vous aux propriétés de mon S3 mini, notamment le getBattLevel.
    Maintenant, toutes les requêtes que je fais conduisent à « la requête n’a pas été exécutée ».
    J’ai pourtant bien mis la clé API et les adresses IP avec leur port sur téléphone et tablette, je ne vois pas ce que je peux faire d’autre.
    C’est d’autant plus curieux étant donné que depuis l’onglet “équipement” sur le plugin JPI, je peux accéder aux propriétés de mon S3 par le bouton “lien vers équipement JPI”
    Avez-vous une idée pour résoudre ce problème ?

    1. Bonsoir, désolé, mais là avec ce que vous donnez … je ne pourrais pas vous aider.
      Je vous conseille de sortir vos logs (que ce soit côté plugin JPI, côté serveur PAW et côté serveur JPI).
      Passez sur le forum sur le fil du plugin JPI.

  25. Bonjour,
    J’ai déjà tenté ma chance sur le forum JPI mais je n’ai eu droit à aucune réponse.

    Pour faire très simple, j’ai ajouté une commande sur le plugin JPI avec pour nom : essai jpi S3 mini et action : getBattLevel
    Voilà ce que j’obtiens dans le log du plugin JPI :
    [2019-05-14 08:55:18][INFO] : Execution de la commande : essai jpi S3 mini
    [2019-05-14 08:55:19][DEBUG] : Requete lancée pour la commande essai jpi S3 mini : http://192.168.1.xx:xxxx/?action=getBattLevel&&&__JPIPLUG=1 – Résultat : 45
    [2019-05-14 08:55:19][ERROR] : La requete pour la commande essai jpi S3 mini n’a pas été exécutée

    Le résultat est donc bien trouvé (45%), mais il n’apparaît pas dans Jeedom.

    Pour le serveur JPI, (les logs ce sont les journaux je pense), ils sont vides excepté le journal des évènements qui indique :
    – 14/05/19 08:55:19 – HTTP_EVENT déclenché – http action: getBattLevel – CLIENT: 192.168.1.xx (Plugin Jeedom JPI)
    – 14/05/19 08:55:19 – http_event – scénario: __DEFAULT__
    – 14/05/19 08:55:19 – http_event – action: getBattLevel => 2 [45]
    – 14/05/19 08:55:19 – http_event – action: httpReturn => 1 [OK]
    – 14/05/19 08:55:19 – HTTP_EVENT terminé

    Pour le serveur Paw, je n’ai dans son log que : # Start of PAW logfile.

    Merci de votre aide.

  26. Benjamin,

    juste pour info, depuis la MJ du plugin BLEA, et en faisant ta modif, il n’y a plus rien qui remonte, je vais voir de mon côté pour modifier/adapter pour récupérer les infos, parce qu’une fois qu’on y a goûter, c’est difficile de s’en passer.
    Merci pour tout 🙂

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *