Non du tout le principe même de l’intégration n’est pas le même et la récupération du code est pas prevue.
La prochaine maj c’est juste une amélioration du fichier de config suite au retour que l’on a fait au développeur qui a géré cela sur deconz.
Yep, pour des raison de sécurité, le code ne sera jamais visible via l’API, trop sensible si quelqu’un sniffe les trames.
Il y a un PR pour gérer plusieurs code et le RFID, mais il bouge pas beaucoup …
Par contre tu peux utiliser les touches spéciales, comme le SOS (ça dépend des claviers)
C’est fait et fonctionnel. Mais d’après ce que j’ai compris il le mettrons pas en stable toute suite, ils veulent implémentée d’autres amélioration avant. L’idée etant de pas tout faire en même temps pour pas tout destabiliser.
1 « J'aime »
Je continue à mettre en plac cet équipement.
Actuellement, lorsque je tape le bon code, puis un bouton, j’ai un etat pour ce bouton, que je repercute sur un virtuel, pour declencher mes scenarios en fonction de l’etat.
Problème, si je change l’etat de mon alarme, à partir d’autre chose que le clavier ( scenario, telephone, badge, etc…) je peux mettre mon virtuel à jour, mais pas mon clavier.
Du coup, je ne peux plus utiliser mon clavier par la suite pour l’un de ses etats, car s’il est deja en mode « alarme activée », et que je refais une activation de l’alarme, cela ne fonctionnera pas.
quelqu’un verrait une solution svp ? est il possible d’envoyer une commande REST à partir de jeedom par ex ?
Merci
J’ai prévu de faire ça sur mon jeedom a mon retour. J’avais commencé à regarder. Je pense qu’il faudra passer soit par un curl soit peut être par le plugin script.
Il faut passer une commande de changement d’état du clavier (de l’alarme deconz en fait) a chaque changement de l’état jeedom.
Alors l’état du systeme est gèré par l’AS, pas le clavier, c’est un élément passif qui demande lui même l’état de l’alarme a l’AS.
Donc les requetes sont a faire a l’AS.
Et quand tu passes devant le clavier, celui ci demande l’état a afficher a l’AS, toutes les commandes sur le clavier sont « read only » et ne sont mise a jour qu’en cas d’interaction (comme les interrupteurs, donc il faut se baser sur la config de l"AS (si tu as plusieurs clavier l’un ne peut pas agir sur le second, c’est l’AS qui centralise le tout)
Après il y a une issue que je ne retrouve pas qui ressemble a la tienne, les topics sont trop long a lire, mais il y a une suite d’action a faire (configurer code0, rajouter le clavier a l’AS, inclure le clavier, ect …) Et en général l’ordre n’est pas respecté, donc une fois que tout est mit en place, il suffit de ne rien effacer, et de re-inclure le clavier, ça marcherait mieux car tout est deja en place, prêt a le recevoir.
C’est réglé (c’est le changement de la beta). Il manquait le second remining qui faisait que l’état de l’as etait pas répercuter par le clavier en cas de changement fait par autre chose que le clavier.
1 « J'aime »
J’ai reussi a le faire, grace au plugin script, si cela interesse des gens voici les infos.
Etape 1 - il faut installer Request2.php, on se connecte donc en SSH sur son jeedom et on tape
pear install HTTP_Request2-2.5.1
Etape 2 - installer / activer le plugin script
Etape 3 - on créé un nouveau script, on, l’active
Etape 4 - dans les commandes, on ajoute une nouvelle commande script, puis on clique sur le bouton vert, pour faire un nouveau script, et on y colle :
<?php
require_once 'HTTP/Request2.php';
$request = new HTTP_Request2("http://192.168.1.100:8484/api/F5D2F4D7SF4/alarmsystems/1/disarm");
$request->setMethod(HTTP_Request2::METHOD_PUT);
$request->setHeader('Content-type: application/json');
$request->setBody('{"code0":"458682"}');
$response = $request->send();
?>
Etape 5 - on remplace F5D2F4D7SF4 par sa propre clé API et disarm par la fonction que l’on veut faire, puis donne un nom à la commande. Les fonctions dispos sont : disarm, arm_night, arm_stay, arm_away
En esperant que ca en depanne certains 
Ce sujet date un peu, je pensais que ce clavier était bien pris en charge par Deconz depuis… mais en fait pas de changement depuis 2022 
Avec mon Deconz mis a jour version 2.30.2, grace aux commandes HTTP, j’ai réussi a rendre fonctionnel un clavier. Merci ! Etonnamment j’ai un 2eme clavier qui s’inclut mais pourtant celui-ci n’est pas fonctionnel : il semble ne plus répondre a Deconz une fois l’inclusion faite (avant de tenter un armemement ou désarmement, quand j’appuie sur les boutons, aucun signe de vie, et j’ai réinclus plusieurs fois) Je me demande si vouloir utiliser 2 claviers n’est pas problematique ? qu’en pensez vous @Idaho947 @franck67 @HugoVal11 ?
Je pense, inclure un clavier ne suffit pas, il faut configurer tout un « alarm system ».
Car le clavier seul ne suffit pas, il faut un systeme complet pour gerer le code par exemple.
Pour home bridge et Home assistant leur plugin le gere, mais pour jeedom j’en sais rien
https://dresden-elektronik.github.io/deconz-rest-doc/endpoints/alarmsystems/
Pour ajouter un clavier Alarm Systems - deCONZ REST-API
After pairing a keypad as sensor, it’s automatically added to the default alarm system with id “1”.
Donc si il y en a un c’est automatique, pour 2 je sais pas.
Oui j’ai suivi la doc et j’ai créé le alarmsystem dans deconz avec API REST, j’ai choisi le code et tout fonctionne parfaitement avec le 1er clavier.
voici le 1er clavier qui est OK.
A noter :j’ai du ajouté moi mem la commande Statut (2c-0501.state::action)
Voici les infos brutes :
{
"42": {
"capabilities": {
"otau": {
"file_version": 131077,
"image_type": 915,
"manufacturer_code": 4117
},
"sleeper": false
},
"config": {
"battery": 100,
"on": true,
"reachable": true
},
"ep": 44,
"etag": "0828c92d4143a3bb0ca607f6af23aac2",
"lastannounced": "2025-05-23T10:47:07Z",
"lastseen": "2025-05-24T11:53Z",
"manufacturername": "frient A\/S",
"modelid": "KEPZB-110",
"name": "AncillaryControl 42",
"nwkaddress": "0x1D98",
"state": {
"action": "disarmed",
"lastupdated": "2025-05-23T13:54:28.356",
"panel": "exit_delay",
"seconds_remaining": 0
},
"swversion": "2.0.5",
"type": "ZHAAncillaryControl",
"uniqueid": "00:15:bc:00:43:00:5e:75-2c-0501"
},
"44": {
"capabilities": {
"otau": {
"file_version": 131077,
"image_type": 915,
"manufacturer_code": 4117
},
"sleeper": false
},
"config": {
"battery": 100,
"on": true,
"reachable": true
},
"ep": 44,
"etag": "944956087f1ed20857662c37d7919d0f",
"lastannounced": "2025-05-23T09:59:01Z",
"lastseen": "2025-05-24T11:53Z",
"manufacturername": "frient A\/S",
"modelid": "KEPZB-110",
"name": "Alarm 44",
"nwkaddress": "0x1D98",
"state": {
"alarm": false,
"lastupdated": "2025-05-24T11:53:09.162",
"lowbattery": false,
"tampered": false
},
"swversion": "2.0.5",
"type": "ZHAAlarm",
"uniqueid": "00:15:bc:00:43:00:5e:75-2c-0500"
}
}
Le 2eme clavier :
Je n’ai pas l’image du capteur mouvement
une fois l’inclusion, plus aucune remonté venant du clavier
Le clavier est bien ajouté au alamsystem avec l’api rest mais comme rien ne remonte dans le noeud ….
Pourtant dans le fichier de log Deconz, J’ai ceci:
10224|[2025-05-24 10:33:39] INFO : Send to jeedom : {'00212EFFFF04F155': {'attr': {'lastseen': '2025-05-24T08:33Z'}, 'e': 'changed', 'id': '49', 'r': 'sensors', 't': 'event', 'uniqueid': '00:15:bc:00:43:00:62:56-2c-0501'}}
10225|[2025-05-24 10:33:39] INFO : Send to jeedom : {'00212EFFFF04F155': {'attr': {'lastseen': '2025-05-24T08:33Z'}, 'e': 'changed', 'id': '50', 'r': 'sensors', 't': 'event', 'uniqueid': '00:15:bc:00:43:00:62:56-2c-0500'}}
et voici les infos brutes :
{
"49": {
"capabilities": {
"otau": {
"file_version": 131077,
"image_type": 915,
"manufacturer_code": 4117
},
"sleeper": false
},
"config": {
"battery": 0,
"on": true,
"reachable": true
},
"ep": 44,
"etag": "d57e1257504f8aaf72de20cf28af4390",
"lastannounced": "2025-05-23T20:03:39Z",
"lastseen": "2025-05-24T08:33Z",
"manufacturername": "frient A\/S",
"modelid": "KEPZB-110",
"name": "AncillaryControl 49",
"nwkaddress": "0x3DC0",
"state": {
"action": "disarmed",
"lastupdated": "none",
"panel": "exit_delay",
"seconds_remaining": 0
},
"swversion": "2.0.5",
"type": "ZHAAncillaryControl",
"uniqueid": "00:15:bc:00:43:00:62:56-2c-0501"
},
"50": {
"capabilities": {
"otau": {
"file_version": 131077,
"image_type": 915,
"manufacturer_code": 4117
},
"sleeper": false
},
"config": {
"battery": 0,
"on": true,
"reachable": true
},
"ep": 44,
"etag": "bdc8fbf13389d6cc07da6eaf50263b20",
"lastannounced": "2025-05-23T20:03:39Z",
"lastseen": "2025-05-24T08:33Z",
"manufacturername": "frient A\/S",
"modelid": "KEPZB-110",
"name": "Alarm 50",
"nwkaddress": "0x3DC0",
"state": {
"alarm": false,
"lastupdated": "none",
"lowbattery": false,
"tampered": false
},
"swversion": "2.0.5",
"type": "ZHAAlarm",
"uniqueid": "00:15:bc:00:43:00:62:56-2c-0500"
}
}
voici les logs d’inclusion su 2eme clavier :
21:41:17:797 send permit join, duration: 65
21:41:19:322 APS-DATA.indication from unknown node 0x0015BC0043006256
21:41:19:356 APS-DATA.indication from unknown node 0x0015BC0043006256
21:41:19:361 CTRL create node 0x0015BC0043006256, nwk: 0x3DC0
21:41:19:377 device announce 0x0015BC0043006256 (0x3DC0) mac capabilities 0x80
21:41:19:377 set fast probe address to 0x0015BC0043006256 (0x3DC0)
21:41:19:377 FP indication 0x0000 / 0x0013 (0x0015BC0043006256 / 0x3DC0)
21:41:19:377 ... (0x0015BC0043006256 / 0x3DC0)
21:41:19:377 device announce 0x0015BC0043006256 (0x3DC0) mac capabilities 0x80
21:41:19:381 ZDP get node descriptor for 0x3DC0
21:41:19:691 DB UPDATE device_descriptors SET data = x'024080151052dc05002cdc0500', timestamp = 1748029279 WHERE device_id = (SELECT id FROM devices WHERE mac = '00:15:bc:00:43:00:62:56') AND endpoint = 0 AND type = 2
21:41:19:691 DB INSERT INTO device_descriptors (device_id, endpoint, type, data, timestamp) SELECT id, 0, 2, x'024080151052dc05002cdc0500', 1748029279 FROM devices WHERE mac = '00:15:bc:00:43:00:62:56'
21:41:19:701 FP indication 0x0000 / 0x8002 (0x0015BC0043006256 / 0x3DC0)
21:41:19:701 ... (0x0015BC0043006256 / 0x3DC0)
21:41:19:701 ZDP indication search sensors 0x0015BC0043006256 (0x3DC0) cluster 0x8002
21:41:19:702 ZDP get active endpoints for 0x3DC0
21:41:19:988 FP indication 0x0000 / 0x8005 (0x0015BC0043006256 / 0x3DC0)
21:41:19:988 ... (0x0015BC0043006256 / 0x3DC0)
21:41:19:988 ZDP indication search sensors 0x0015BC0043006256 (0x3DC0) cluster 0x8005
21:41:19:989 ZDP get simple descriptor 0x01 for 0x3DC0
21:41:20:096 FP indication 0x0000 / 0x8005 (0x0015BC0043006256 / 0x3DC0)
21:41:20:096 ... (0x0015BC0043006256 / 0x3DC0)
21:41:20:096 ZDP indication search sensors 0x0015BC0043006256 (0x3DC0) cluster 0x8005
21:41:20:341 DB UPDATE device_descriptors SET data = x'01c9c0010000020500060000', timestamp = 1748029280 WHERE device_id = (SELECT id FROM devices WHERE mac = '00:15:bc:00:43:00:62:56') AND endpoint = 1 AND type = 4
21:41:20:342 DB INSERT INTO device_descriptors (device_id, endpoint, type, data, timestamp) SELECT id, 1, 4, x'01c9c0010000020500060000', 1748029280 FROM devices WHERE mac = '00:15:bc:00:43:00:62:56'
21:41:20:348 FP indication 0x0000 / 0x8004 (0x0015BC0043006256 / 0x3DC0)
21:41:20:348 ... (0x0015BC0043006256 / 0x3DC0)
21:41:20:348 ZDP indication search sensors 0x0015BC0043006256 (0x3DC0) cluster 0x8004
21:41:20:348 ZDP get simple descriptor 0x2C for 0x3DC0
21:41:20:614 FP indication 0x0104 / 0x0019 (0x0015BC0043006256 / 0x3DC0)
21:41:20:614 ... (0x0015BC0043006256 / 0x3DC0)
21:41:20:819 DB UPDATE device_descriptors SET data = x'2c04010104000600000300200000050100050b0403000a0001051900', timestamp = 1748029280 WHERE device_id = (SELECT id FROM devices WHERE mac = '00:15:bc:00:43:00:62:56') AND endpoint = 44 AND type = 4
21:41:20:820 DB INSERT INTO device_descriptors (device_id, endpoint, type, data, timestamp) SELECT id, 44, 4, x'2c04010104000600000300200000050100050b0403000a0001051900', 1748029280 FROM devices WHERE mac = '00:15:bc:00:43:00:62:56'
21:41:20:831 FP indication 0x0000 / 0x8004 (0x0015BC0043006256 / 0x3DC0)
21:41:20:831 ... (0x0015BC0043006256 / 0x3DC0)
21:41:20:831 ZDP indication search sensors 0x0015BC0043006256 (0x3DC0) cluster 0x8004
21:41:21:013 FP indication 0x0104 / 0x0000 (0x0015BC0043006256 / 0x3DC0)
21:41:21:013 ... (0x0015BC0043006256 / 0x3DC0)
21:41:21:218 FP indication 0x0104 / 0x0000 (0x0015BC0043006256 / 0x3DC0)
21:41:21:218 ... (0x0015BC0043006256 / 0x3DC0)
21:41:21:288 DEV found DDF for 0x0015BC0043006256, path: /usr/share/deCONZ/devices/frient/kepzb-110_keypad.json, result: 1
21:41:21:331 ZDP get active endpoints for 0x3DC0
21:41:21:513 ZDP get simple descriptor 0x01 for 0x3DC0
21:41:21:630 ZDP get simple descriptor 0x2C for 0x3DC0
21:41:21:747 DEV found DDF for 0x0015BC0043006256, path: /usr/share/deCONZ/devices/frient/kepzb-110_keypad.json, result: 1
je suis allé voir dans DB deconz pour comparer les 2 et voici (id=37 pour le clavier 1 et id=38 pour le 2eme):
sqlite> select * from devices ....
37|00:15:bc:00:43:00:5e:75|1747994341|7576
38|00:15:bc:00:43:00:62:56|1748029279|15808
sqlite> select * from device_descriptors where id=38;
38|16|0|1|4||1622477561
sqlite> select * from device_descriptors where id=37;
37|16|0|0|2|@▒!Y?|1622477560
sqlite> select * from device_descriptors where endpoint=44;
85|37|0|44|4|,|1747994342
88|38|0|44|4|,|1748029280
sqlite> select * from device_descriptors order by device_id;
83|37|0|0|2|@▒R▒|1747994341
84|37|0|1|4|▒▒|1747994342
85|37|0|44|4|,|1747994342
86|38|0|0|2|@▒R▒|1748029279
87|38|0|1|4|▒▒|1748029280
88|38|0|44|4|,|1748029280
sqlite> select * from sub_devices....
19|00:15:bc:00:43:00:5e:75-2c-0501|37|1747996357
20|00:15:bc:00:43:00:5e:75-01-0406|37|1747996357
21|00:15:bc:00:43:00:5e:75-2c-0500|37|1747998668
23|00:15:bc:00:43:00:62:56-2c-0501|38|1748029281
24|00:15:bc:00:43:00:62:56-2c-0500|38|1748029281
Alors pour le coté DDF, je viens de vérifier il ya un PR récent Updated DDF for frient Intelligent Keypad (KEPZB-110) by ebaauw · Pull Request #8154 · dresden-elektronik/deconz-rest-plugin · GitHub
Qui crée un ZHAAlarm 01-0501 a la place du ZHApresence 01-0406.
Le premier a du être inclu avant cette mise a jour, d’où le capteur en plus.
Mais ça n’explique pas le probleme.
Si jamais tu essayes cette commande, tu as quoi comme resultat ?
https://dresden-elektronik.github.io/deconz-rest-doc/endpoints/alarmsystems/#get-all-alarm-systems
Je vais demander de mon coté si quelqu’una deja reussi ca.
Oui tu as raison : le présence 01-0406 n’apparaît pas pour le 2ème. Sans doute car la version de deconz était la 2.18 quand j’ai inclus la 1er clavier, et ensuite j’ai mis à jour en 2.30 et l’ info Alarme est apparu (qui vaut toujours 0 pour le 1er clavier d’ailleurs) Le champ a rajouter vraiment important est le « 2c-0501.state::action » car il permet de voir le statut de l’alarmsystem.
Voici le resultat du « GET /api/…alarmsystems » , ci dessous , on voit bien les 2 claviers que j’ai inclus avec la commande PUT ( j’ai pris l’id avec le sous devices 2c-0500…)
Les 2 claviers comprennent en effet un ZHAAncillaryControl « 2c-0501 », et un ZHAAlarm « 2c-0500 »
{"1":
{
"config":{
"armed_away_entry_delay":120,"armed_away_exit_delay":120,"armed_away_trigger_duration":120,"armed_night_entry_delay":120,"armed_night_exit_delay":120,"armed_night_trigger_duration":120,"armed_stay_entry_delay":120,"armed_stay_exit_delay":120,"armed_stay_trigger_duration":120,"armmode":"disarmed","configured":true,"disarmed_entry_delay":0,"disarmed_exit_delay":0
},
"devices":{
"00:15:bc:00:43:00:5e:75-2c-0500":{"armmask":"none"},
"00:15:bc:00:43:00:62:56-2c-0500":{"armmask":"none"}
},
"name":"default","state":{"armstate":"disarmed","seconds_remaining":0
}
}
}
Alors si j’ai bien compris il ne faut pas regarder l’état des claviers, normal car ils peuvent avoir un état différent, mais l’état de l’alarmsystem.
Par contre on voit bien les 2 claviers mais pas leur ID dans l’alarmsystem.
Edit:
Je crois qu’il y a un soucis, tu as dans l’alarmsystem des appareils qui finissent par 0500 et ca devrait etre 0501 pour les ZHAAncillaryControl
En effet, mais le 1er clavier fonctionne pourtant… Nouvel essai : j’ai supprimé les 2 id terminant par 500 et j’ai ajouté ceux par 501 dans l’alarmsystem.
Résultat : le 1er marche toujours (code reconnu et mis à jour du statut de l’alarme) mieux maintenant les attribut ‘secondes restantes’ et ´panel’ sont mis à jour.
Le 2ème : toujours pas de mise à jour dans Jeedom (pas de code reconnu et toujours ‘date derniers communication’ vide) mais ‘secondes restantes’ et ´panel’ sont mis à jour.
En gros maintenant les 2 claviers sont bien connectés avec l’alarmsystem, sauf que le 2ème a l’air d’ignorer Jeedom
En fait c’est le problème : car même avant que je crée l’alarmsystem avec l’APIREST, le clavier 1 communiquait avec Jeedom( date de dernière communication ok et champ action valait ‘not ready’) alors que le clavier 2 est inclus , et il est ´vu’ par Jeedom mais il n’envoie de lui même rien à Jeedom. Dans Deconz et la page des noeuds, il y a INVALIDE dans la colonne Date de communication: depuis l’inclusion aucune info reçu du module meme la batterie est à zéro car aucune trame reçu avec l’info.
je vois que tu arrives a avoir les logs deconz.
Tu aurais les logs deconz quand tu tapes le code sur celui qui « ne marche pas ».
Activité fructueuse aujourd’hui : j’ai réussi a faire fonctionner le 2eme clavier
Seul moyen : retrograder en 2.28 deconz (car le derniere adaptation du DDF a été publié dans la 2.29). ainsi le clavier2 a été inclus comme le 1er (avec l’image du detecteur de mouvement et le ZHAPresence +ZHAAncillaryControl ). j’ai remis la dernière version 2.30.2, et le 2eme est devenu comme le 1er et cette fois les infos remontent (ZHAAncillaryControl et ZHAAlarm)
Donc pour conclure, la modification faite dans la 2.29 (https://github.com/dresden-elektronik/deconz-rest-plugin/pull/8154 n’est pas au point. mes 2 claviers fonctionnent uniquement parceque je les ai inclus dans une version antérieure… merci @HugoVal11 pour ton aide comme toujours 
Donc pour résumer, à ce jour, voici ce que je dirais concernant l’intégration du clavier Frient KEPZB-110 dans jeedom avec un clé conBee2 et le plugin Deconz. C’est plus complexe qu’avec zigbeeToMqtt forcement. Il y a un objet « alarmsystem » qui symbolise l’alarme et on ne peut pour l’instant interagir avec cette alarme qu’avec l’API REST de deconz. il faut lire et comprendre cette page. J’ai installé en SSH « HTTP_Request2-2.5.1 » ce qui permet dans un bloc code d’envoyer les requêtes. Ce que j’écris est valable en ce moment, en fonction de la version de Deconz actuelle : 2.30.2. sans doute les prochaines versions simplifieront la gestion…
- Avant d’inclure le clavier et si ce n’est pas encore fait, activer dans Deconz l’objet « alarmsystem » : avec l’API REST
- En profiter pour définir dans cet objet le code (unique) de l’alarme, toujours avec l’API REST.
- Pour inclure le clavier , a partir de la version 2.29 de Deconz, cela n’a pas fonctionné dans mon cas (inclusion faite mais pas de comm avec le device). Ma conclusion est qu’il faut que Deconz soit au max en 2.28 (rétrograder via SSH si nécessaire)
- si vous êtes en 2.28 alors il faut mettre ,avant d’inclure, le fichier DDF du clavier en Gold (avec SSH, aller éditer le fichier et remplacer Bronze par Gold)
- Inclure le clavier (ne pas hésiter à faire le rest usine avant et être patient…
- 2 sous devices sont créés : un ZHAAncillaryControl et un ZHAPresence
- A ce stade, les devices ne sont pas fonctionnels. il faut remettre la dernière version de Deconz, actuellement la 2.30.2 (DDF est en Gold ici)
- Alors le ZHAPresence est remplacé par un ZHAAlarm, et des nouveaux champs apparaissent
- le module créé AncillaryControl XX avec 4 commandes ne sert a rien. ne garder que l’autre (celui créé avec les infos Actif, Joignable) , son nom est du type Alarm XX ou Sensor XX.
- Il manque un champ important dans ce module Alarm XX: il faut rajouter manuellement une commande de type Info/Autre avec le paramètre « 2c-0501.state::action ». je l’ai appelé « Statut »
- Normalement, le clavier a été rajouté dans l’objet alarmsystem, mais vérifier et le rajouter si besoin, avec l’API REST (ce sont les uniqueid terminant par 01-0501 qui doivent apparaitre dans la liste des devices de l’alarmsystem, sachant que dans mon cas, j’avais rajouté manuellement l’uniqueid terminant par 01-0500 et cela avait fonctionné pour un clavier…)
Maintenant, tout doit fonctionner :
- en tapant le code puis l’un des boutons de modes d’alarme (away, night, stay), le clavier passe l’alarme dans un etat Activé
- le champ Statut peut valoir : disarmed, armed_away, armed_stay, armed_night, already_disarmed, not_ready (=alarmsystem non activé), invalid_code
- en interrogeant par API REST l’objet alarmsystem, on peut récupérer le statut de l’alarme (car la commande rajoutée Statut du clavier peut ne pas être mis a jour si l’alarme a été activée par API) avec les mêmes valeurs
- en tapant le code puis le bouton cadena ouvert, le clavier passe l’alarme dans un etat désactivé
- le bouton SOS n’est pas géré
- il y a des paramètres modifiables dans l’objet alarmsystem (avec l’API REST) comme le temps que le clavier met a clignoter/bipper pour signifier que l’alarme va changer de mode.
- il y a un capteur de mouvement intégré dans le clavier,ce capteur fait que la led s’allume temporairement en vert ou rouge suite à un mouvement devant le clavier selon le statut de l’alarme
- il y a la possibilité d’ajouter à l’objet alarmsystem des modules deconz pour déclencher l’alarme si elle est active (fenetre, porte, mouvement), toujours avec l’API REST, mais je ne l’ai pas testé.
- j’ai testé le fait d’activer ou désactiver l’alarme sans le clavier : avec l’API REST, cela fonctionne. le clavier est alors « avertit » du changement d’état, mais par nécessairement tout de suite
Je vais tester plus profondément ce clavier frient/conBee/deconz, mes remarques déjà :
- les commandes info Batterie, Alarme, Alerte, Presence, Panel ne semblent pas fonctionnelles
- les commandes Actif/Joignable sont les infos classiques « on », et « reachable »
- seul la commande créée manuellement « Statut » est au final pertinente
- il y a une commande info « Secondes restantes » qui fonctionne et qui correspond au timer activé quand l’alarme est activé (décompte dont la valeur est modifiable via l’API REST, par défaut 120 secondes).pertinent pour savoir qu’un clavier vient d’activer/desactiver l’alarme
- pas possibilité de commander les LED (ou alors a voir quelle commande a rajouter ou corriger le DDF?)
- pas possibilité de récupérer la présence (ou alors a voir quelle commande a rajouter ou corriger le DDF?)
- un seul code secret semble pouvoir être géré (paramètre code0).
- pas de badge RFID possible (ou alors sans doute mettre le code du badge dans code0 mais alors aucun code saisissable via le clavier)
- avec 2 claviers, cela fonctionne, mais la commande « Statut » d’un clavier ne se met pas à jour si l’autre clavier fait changer l’état de l’alarme. pas critique cependant, il faut interroger l’alarmsystem pour avoir le bon statut
- avec 2 claviers, si l’alarme a été activée sur un clavier et que la désactivation se fait sur le 2eme ou si l’alarme a été mise par API et non par un clavier, à la 1ere touche appuyée, le clavier peut biper et changer de statut (celui de l’alarmsystem), mais la touche appuyée et bien mémorisée et il faut continuer à saisir le code par exemple.
à suivre…