Code pour vérifier états équipement

[Michel57189]

Bonsoir,

J’ai de temps en temps des équipements sous deconz qui ne sont plus en ligne, pour des raisons X et Y notamment liées à la disposition (éloignement) de mes équipements.

J’aimerais mettre un bout de code dans un scénario pour balayer mes équipements Deconz et me compter et/ou me lister les équipements qui ne sont pas ‹ ‹ reachable › ›.
Et … je ne sais pas faire !

Je ne suis pas informaticien du tout. J’ai fait un peu de Visual Basic jadis (on ne se moque pas)
Je m’intéresse un peu au PHP mais surtout je ne sais pas où trouver comment on adresse les objets jeedom … par exemple l’objet ‹ ‹ équipement › › et ses propriétés, notamment la propriété ‹ ‹ reachable › ›

Help please

Merci d avance

[olive]

@bonsoir @Michel57189

sans aller aussi loin dans la configuration avancée de l’équipement tu a
une notion d’alertes de communications.
celle-ci est réglable en minutes

celle-ci t’affichera une pastille jaune et un avertissement dés que le temps sans communication sera dépassé.

bonne soirée

[Michel57189]

Merci @olive,

Je vais déjà essayer ça sur un équipements qui pose de temps en temps des problèmes …

mais j’aimerais qd même aussi aboutir sur ce bout de code pour les tester tous mes équipements

[sebfar]

Personnellement j’utilise watchdog

[marmoul]

Pareil c’est vraiment pas mal et simple à configurer

[Bben]

Salut Michel,

pour du code :
trouver les eqlogic (equipement) de deconz :

$eqLog = eqLogic::byType('deconz', true); // le true pour n'avoir que les activés

foreach($eqLog as $eq){
  
   $scenario->setLog($eq->getName()." / " . $eq->getHumanName());
}

pour tester si en alert, je pense selon les test du core : (attention pas testé, sans garantie, mais le nom de la fonction sonne bien):

$eq->getAlert()
ou
$eq->getMaxCmdAlert()

d’interressant dans les eq deconz, tu dois avoir :
$eq->getLastCommunication()

a tester en fonction de l’heure actuel (cf les méthode date et affilié de php)
j’ai l’impression que c’est renseigné pour les équipement sur pile ceci dit…

[Michel57189]

@marmoul, @sebfar et @Bben,

Merci beaucoup pour votre aide … cela étant, je n’ai toujours pas trouvé la solution à mon pb !

Le plugin WatchDog, je ne connaissais pas. J’ai balayé la doc. Ca semble effectivement facile à utiliser mais l’auteur @sigalou, parle de tester des NUTs ou des équipements IP. Je ne sais pas comment écrire le test d’un équipement Zigbee sous Deconz. Mais c’est vrai que ça semble être un très bon plugin que je vais très surement installer pour certains équipements (mon ‹ ‹ ouvre porte de garage › › Meross par exemple).

@Bben, ton post m’a permis d’avancer dans le codage. J’ai fait un petit scenario qui liste bien tous les équipements Deconz actifs et envoie leur nom dans les logs. mais je n’arrive pas à afficher s’ils sont joignables ou pas …
->getAlert() ne remonte rien
->getMaxCmdAlert() remonte ‹ none › quelque soit l’état de l’équipement
->getLastCommunication() remonte bien une date mais seulement sur les capteurs de température ou d’humidité par exemple car il envoient très régulièrement une info. Pour un actionneur de lampe, cette date est mise à jour seulement quand il y a une action sur la lampe. Donc je ne peux pas utiliser cette info non plus.

a suivre …

[Phpvarious]

Bonsoir,
Quand j’utilisé Deconz j’ajoutai une commande info directement dans l’équipement, et je pointai directement le Logical ID sur l’info « reachable » qui était accessible directement dans la config du module. J’utilise uniquement du Xiaomi donc je ne saurait dire si cette info est dispo sur d’autres marques.
Voici un exemple pour une prise Xiaomi :
La partie Config

La Commande Info rajouter dans l’équipement :

Ainsi j’avais un scénario avec comme déclencheur cette info, pour me notifier la perte d’un capteur.

[Michel57189]

Hello @Phpvarious

Merci de regarder mon pb …
Je ne suis pas sur de savoir créer correctement la commande

Par exemple, un des équipements que je perds souvent est un relais triple Orvibo cm10zw
D’ailleurs ce matin il est encore ‹ ‹ out › › (voir ci dessous)

{
    "27": {
        "etag": "b047b481ebc9f03e9c501cfbd87562fe",
        "hascolor": false,
        "lastannounced": "2021-06-25T07:15:05Z",
        "lastseen": "2021-06-25T07:15Z",
        "manufacturername": "Unknown",
        "modelid": null,
        "name": "Door Lock Unit 27",
        "state": {
            "alert": "none",
            "on": false,
            "reachable": false
        },
        "swversion": null,
        "type": "Door Lock Unit",
        "uniqueid": "00:12:4b:00:22:cd:ee:a9-01"
    },
    "28": {
        "etag": "b047b481ebc9f03e9c501cfbd87562fe",
        "hascolor": false,
        "lastannounced": "2021-06-25T07:15:05Z",
        "lastseen": "2021-06-25T07:15Z",
        "manufacturername": "Unknown",
        "modelid": null,
        "name": "Door Lock Unit 28",
        "state": {
            "alert": "none",
            "on": false,
            "reachable": false
        },
        "swversion": null,
        "type": "Door Lock Unit",
        "uniqueid": "00:12:4b:00:22:cd:ee:a9-02"
    },
    "29": {
        "etag": "b047b481ebc9f03e9c501cfbd87562fe",
        "hascolor": false,
        "lastannounced": "2021-06-25T07:15:05Z",
        "lastseen": "2021-06-25T07:15Z",
        "manufacturername": "Unknown",
        "modelid": null,
        "name": "Door Lock Unit 29",
        "state": {
            "alert": "none",
            "on": false,
            "reachable": false
        },
        "swversion": null,
        "type": "Door Lock Unit",
        "uniqueid": "00:12:4b:00:22:cd:ee:a9-03"
    }
}

Et mes commandes actuelles :

Le msg d’erreur dit qu’il n’est effectivement pas ‹ ‹ reachable › › qd on lance une commande
data : {« on »:false} erreur : 202 => resource, /lights/28/state, is not modifiable. Device is not reachable.

Tu ferais quoi ??

[mich0111]

Tu dois créer des commandes « info/binaire » nommées comme tu veux, dont les LogicalId seraient « 1.state::reachable » pour le 1er relais, 02.state::reachable pour le 2ème, 03.state::reachable pour le 3ème.

[Bben]

j’avais fait un descritpif pour construire les commande sà partir du json : Conbee/Phoscon persistence des modification de configuration - #24 par Bben

je fait systématiquement l’info battery et reachable sur tous mes équipement zigbee, mais franchement la valeur/qualité de celles-ci est vraiment douteuse…

Il m’arrive très régulièrement que Jeedom me note un module comme non atteignable (mes détecteurs Heiman de fumée), et que l’info reachable ne soit pas valorisée dans l’équipement…

Et bien souvent, cette info ne remonte qu’à l’inclusion et la déconnexion éventuelle. Il faut donc inclure le module, ajouter l’info, et le réinclure pour que ça ai une quelconque valeur. laborieux !
A noter que ces valeurs remontent très aléatoirement selon les marques, modules, la couleur des libellules, … , parfois au bout de plusieurs semaines… ou plus … ou jamais!