Intégration de la Sirène d'alarme Heiman hs2wd-e zigbee dans Jeedom

funben · Décembre 14, 2019, 3:20

Bonjour,
je viens d’acheter deux sirène Heiman hs2wd-e zigbee Lien ici

J’ai pu les ajouter à Jeedom, mais aucune commande n’a été créée, je n’arrive pas à les créer « à la main »
Comment faire ?

Voici ce que j’ai tenté, sans succès

Ci-après les « information brutes »

{
« 5 »: {
« etag »: « 800d84aa2175b10169220afcfb98fde1 »,
« hascolor »: false,
« manufacturername »: « Heiman »,
« modelid »: « WarningDevice »,
« name »: « Warning device 5 »,
« state »: {
« alert »: « none »,
« reachable »: true
},
« swversion »: « 2018.03.21 »,
« type »: « Warning device »,
« uniqueid »: « 00:0d:6f:00:13:c6:e0:39-01 »
},
« 14 »: {
« config »: {
« battery »: null,
« on »: true,
« pending »: [],
« reachable »: true
},
« ep »: 1,
« etag »: « 800d84aa2175b10169220afcfb98fde1 »,
« manufacturername »: « Heiman »,
« modelid »: « WarningDevice »,
« name »: « Alarm 14 »,
« state »: {
« alarm »: false,
« lastupdated »: « none »,
« lowbattery »: false,
« tampered »: false
},
« swversion »: « 2018.03.21 »,
« type »: « ZHAAlarm »,
« uniqueid »: « 00:0d:6f:00:13:c6:e0:39-01-0500 »
}
}

Yves19 · Décembre 14, 2019, 6:00

Essaie plutôt ceci :
pour activation alarme la commande Action est : 01-0500.on::1
pour désactivation alarme la commande Action est : 01-0500.on::0
pour l’état d’activation la commande Info est: 01-0500.state::alarm
pour l’état de tentative d’effraction sur l’alarme la commande Info est : 01-0500.state::tampered
pour le niveau d’alarme courant la commande Info est : 01.state::alert

funben · Décembre 16, 2019, 8:33

Bonjour yves, merci pour ta réponse,
J’ai tenté les commandes proposées, mais sans succès. J’avais, avec succès, ajouté les commandes « à la main » sur un autre module, Lien ici mais cette fois ça ne marche pas.
Les commandes infos, ne remontent rien et les commandes actions donnent le résultat ci-dessous :

Erreur lors de la requete : 127.0.0.1:8484/api/1EC213F105/lights/15/state(PUT), data : {« on »:true} erreur : 3 => resource, /lights/15, not available
Erreur lors de la requete : 127.0.0.1:8484/api/1EC213F105/lights/15/state(PUT), data : {« on »:false} erreur : 3 => resource, /lights/15, not available

Yves19 · Décembre 16, 2019, 12:10

Bizarre que Jeedom essaie de faire un PUT avec une light et en ID14 qui n’existe effectivement pas puisque c’est un sensor en ID15 !

Tu peux essayer de faire les requêtes à la main avec l’extension RESTClient de Firefox. J’ai déjà répondu sur comment faire avec cette extension ici https://community.jeedom.com/u/Yves19

et la doc complète ici :

https://dresden-elektronik.github.io/deconz-rest-doc/

HugoVal11 · Décembre 16, 2019, 5:01

Ce serait select ,lselect et blink cf https://github.com/dresden-elektronik/deconz-rest-plugin/issues/565

Et si tu regardes bien ton JSON tu veras qu’il n y a pas de « on » dans le champs « state », donc meme pas la peine d’essayer cette requête.

Pour la faire sonner : {« alert »: « lselect »}

funben · Décembre 18, 2019, 10:35

En fait j’ai deux sirènes, elles ont bien des identifiants en 14 et 15, donc pas de soucis à ce niveau là
Par contre, j’ai utilisé le RESTClient de firefox, j’ai découvert que les sirenes apparaissaient deux fois, en tant que Lights et Sensors. Ci-dessous les résultats des GET et des PUT sur sensors/14 et lights/5 (Notez bien que les uniques ID sont bien identiques)

Bref, c’est déroutant

curl -X PUT -i 'http://192.168.1.16:8484/api/1EC213F105/sensors/14/' --data '{"alarm": "none"}'
RESULTAT : parameter, alarm, not available

curl -X PUT -i 'http://192.168.1.16:8484/api/1EC213F105/lights/5' --data '{"alarm": "none"}'
RESULTAT : method, PUT, not available for resource, /lights/5

curl -X GET -i 'http://192.168.1.16:8484/api/1EC213F105/sensors/14/'
{
  "config": {
    "battery": null,
    "on": true,
    "reachable": false
  },
  "ep": 1,
  "etag": "86787593d4100626aaa557ddd11e4249",
  "manufacturername": "Heiman",
  "modelid": "WarningDevice",
  "name": "Alarm 14",
  "state": {
    "alarm": null,
    "lastupdated": "none",
    "lowbattery": null,
    "tampered": null
  },
  "swversion": "2018.03.21",
  "type": "ZHAAlarm",
  "uniqueid": "00:0d:6f:00:13:c6:e0:39-01-0500"
}


curl -X GET -i 'http://192.168.1.16:8484/api/1EC213F105/lights/5'
{
  "etag": "86787593d4100626aaa557ddd11e4249",
  "hascolor": false,
  "manufacturername": "Heiman",
  "modelid": "WarningDevice",
  "name": "Warning device 5",
  "state": {
    "alert": "none",
    "reachable": true
  },
  "swversion": "2018.03.21",
  "type": "Warning device",
  "uniqueid": "00:0d:6f:00:13:c6:e0:39-01"

curl -X GET -i 'http://192.168.1.16:8484/api/1EC213F105/lights/14/'
RESULTAT : resource, /lights/14, not available

funben · Décembre 19, 2019, 9:02

La nuit portant conseil, j’ai executé avec succès, (en utilisant le RESTClient dans firefox) les commandes suivantes :

curl -X PUT -i ‹ http://192.168.1.16:8484/api/1EC213F105/lights/5/state › --data ‹ {« alert »: « none »} ›
curl -X PUT -i ‹ http://192.168.1.16:8484/api/1EC213F105/lights/5/state › --data ‹ {« alert »: « blink »} ›
curl -X PUT -i ‹ http://192.168.1.16:8484/api/1EC213F105/lights/5/state › --data ‹ {« alert »: « select »} ›
curl -X PUT -i ‹ http://192.168.1.16:8484/api/1EC213F105/lights/5/state › --data ‹ {« alert »: « lselect »} ›

Maintenant, reste à faire fonctionner cela dans jeedom

funben · Décembre 19, 2019, 9:40

Du coup après avoir recherché (sans succès) partout dans les paramètres pour voir si on peut changer l’identifiant qu’utilise Jeedom, j’en appelle @Loic pour parce que je pense que c’est un bug du plugin deconz
Pourrais-tu regarder cela, stp.

Loic · Décembre 19, 2019, 9:46

Parler de bug a chaque fois que ca marche pas comme vous vouelz c’est quand meme fatiguant… Non il n’y a pas de bug suffit de suivre la doc

funben · Décembre 19, 2019, 3:50

Mea culpa, mon objectif était pas de remettre en question la qualité du travail fournit. Il n’y a peut-être pas de bug (au sens ou la doc indique que c’est un comportement normal) cependant avant de poster j’ai eu le sentiment d’avoir bien cherché, j’ai bien lu la doc du plugin :
https://jeedom.github.io/plugin-deconz/fr_FR/
et si j’en crois ce quelle dit … on peut rien faire au niveau de Jeedom
« L’ajout de module n’est pas géré directement pas Jeedom SAS mais par la societé editrice de la gataway Deconz »

Donc je ne suis pas bien sur de savoir sur quelle pied danser :

Ce n’est pas un bug, et c’est normal que le module ne fonctionne pas parce que ce n’est pas prévu par la « société éditrice » ?
Ou bien
Ce n’est pas un bug, si ça peut fonctionner comment faire pour changer l’ID qu’appelle le plugin ?
(Ce n’est pas écris dans la doc du plugin, c’est que ce n’est pas faisable ? ou bien que c’est écrit ailleurs dans un autre coin de la doc)
Merci d’avance @Loic pour tes lumières

Maintenant en ce qui concerne le comportement attendu … oui effectivement, j’aimerai que le plugin se débrouille tous seul pour créer des commandes, même quand il n’a jamais rencontré le périphérique en question. Il me semble que ce serait faisable en parsant les « informations brutes ».
Que je remet ci-après en cas de besoin :

    "5": {
        "etag": "552307541428633589a1b42b9535559d",
        "hascolor": false,
        "manufacturername": "Heiman",
        "modelid": "WarningDevice",
        "name": "Warning device 5",
        "state": {
            "alert": "none",
            "reachable": true
        },
        "swversion": "2018.03.21",
        "type": "Warning device",
        "uniqueid": "00:0d:6f:00:13:c6:e0:39-01"
    },
    "14": {
        "config": {
            "battery": null,
            "on": true,
            "reachable": true
        },
        "ep": 1,
        "etag": "dc8d925e23e7977289db72c119e8a974",
        "manufacturername": "Heiman",
        "modelid": "WarningDevice",
        "name": "Alarm 14",
        "state": {
            "alarm": null,
            "lastupdated": "none",
            "lowbattery": null,
            "tampered": null
        },
        "swversion": "2018.03.21",
        "type": "ZHAAlarm",
        "uniqueid": "00:0d:6f:00:13:c6:e0:39-01-0500"
    }
}

Loic · Décembre 19, 2019, 4:13

Tu mélange 2 chose :

la création des commandes, ca oui c’est au plugin de le faire si l’integration est fini coté deconz
la clef dans l’url ca c’est un soucis de droit d’accès et c’est dans la doc

funben · Décembre 19, 2019, 4:53

J’ai eu beau cherché dans la doc du plugin et dans la doc du core je n’ai pas trouvé, le seul endroit ou j’ai trouvé des droits d’accès c’est au niveau de systeme/utilisateur mais je ne vois pas le rapport.

Là je sèche, donc si quelqu’un connait la réponse et souhaite me la donner, je suis preneur.

Loic · Décembre 19, 2019, 5:01

https://jeedom.github.io/plugin-deconz/fr_FR/#tocAnchor-1-3-1

HugoVal11 · Décembre 19, 2019, 5:28

Alors je sais pas comment tu t’y prend, mais effectivement deconz crée 2 appareils, c’est normal.
Toi tu cherches a agir dessus, donc il te faut prendre celui qui est dans « lights » pas celui des capteurs.

Il faudrait avoir ta procédure précédent celle qui t’a donnée le screen du premier post, c’est a ce moment ou il a du y avoir un raté.

Moi je vois 2 UniqueID différent a chaque fois, donc devrait pas y avoir de problemes avec le plugin.

00:0d:6f:00:13:c6:e0:39-01-0500 > capteur > a éviter pour commencer.
00:0d:6f:00:13:c6:e0:39-01 > « lampe » > a inclure.

Par contre
Erreur lors de la requete : 127.0.0.1:8484/api/1EC213F105/lights/15/state(PUT), data : {“on”:true} erreur : 3 => resource, /lights/15, not available

Ça c’est pas normal pour moi, le plugin est sensé savoir que l’ID 15 vient de « sensors » et pas de « lights », sauf si tu as bidouillé un truc a la main ?

Essayes en repartant de zero et en regardant si tu ne vois pas 2 devices (par sirenes)

funben · Décembre 19, 2019, 6:07

Merci pour tes conseils, j’ai rien bidouillé. Je vais retenter l’inclusion.

HugoVal11 · Décembre 19, 2019, 6:25

Pas besoin de le re-inclure (ca a a l’air bon coté deconz)
Au pire, tu peux le supprimer de jeedom et resychroniser (mais pareil pour moi c’est bon aussi, jeedom l’a bien inclue, vérifier les infos au pire)
Mais je pense que l’erreur est après, quand tu as sélectionne l’appareil et commencé a créer les commandes.

funben · Décembre 19, 2019, 8:01

Du coup, j’ai supprimé les périphérique et recréé les commandes, et c’est là qu’il m’est apparu que la syntaxe de commande n’était pas bonne
le préfixe 01 appelle la lights/5
le préfixe 01-0500 appelle sensors/14

J’ai donc créé les commandes suivantes

01.alert::none //Stop tout
01.alert::blink //Fait clignoter la lumière
01.alert::select //Fait sonner l'alarme
01.alert::lselect //Fait sonner l'alarme longuement

Le résultat « visuel » est dans la capture d’écran ci-dessous.
Je pense que l’on peut encore créer d’autres commandes info, mais je ne suis pas bien sur de la syntaxe. Je suis preneur de conseils.

01.state::alert
01-500.state::tampered
01-500.state::alert

funben · Décembre 19, 2019, 8:15

Je suis débutant sur Jeedom, je découvre tout au fur et à mesure.
D’une manière générale, je trouve que créer ses commandes à la main, quand on n’y connait rien c’est quand même pas à portée de tout le monde.
Je ne sais pas s’il existe de la domotique plug-and-play, intercompatible, et non dépendante du cloud (i.e. sans vendre son âme/ses données/sa maison aux méchants GAFAM et BATX)

PS : Je suis curieux de savoir ou cela étais écris dans la doc.

seb821 · Décembre 19, 2019, 9:00

Pour la plupart des équipements, la création de commandes est automatique. Là c’est plutôt une exception.

Il faut aussi voir que le support de Zigbee / Deconz sur Jeedom est relativement récent (quelques mois), mais aussi tributaire d’un développement tierce (Deconz / Phoscon) sur lequel Jeedom n’a pas la main.

Je pense que par exemple le Z-Wave répondrait à tes attentes. C’est un protocole plus standard mais les équipements sont plus chers. Le Zigbee quant à lui a l’inconvénient de présenter trop de latitude ce qui fait que chaque constructeur fait un peu sa sauce, et cela rend plus compliqué le support de nouveaux équipements.

funben · Décembre 19, 2019, 9:04

J’ai vraiment pas eu de bol, ou alors je suis un avant-gardiste parce que c’est mon deuxième périphérique qui me cause des maux de tête,
Justement, on dirait que les « grand méchants qu’on utilise quand même » se sont rendus compte de la problématique et vont créer un standard domotique. Le temps cela se mette en place et que les périphériques sortent, je pense qu’on va quand même attendre encore 1 ou 2 ans.