Mog a écrit :
ok pour la zw090
(...)
Avez-vous déjà testé la bonne prise en compte dans domoticz des équipement d link.
comme le détecteur de porte dch z510 ?
ou la sirene dch z510 d link ?
La clef z-stick gen5 est en effet un bon modèle. L'autre avantage étant de pouvoir la débrancher pour faire les inclusions: Comme ces dernières doivent se faire controleur et périphérique proche (puissance radio réduite afin de ne pas risquer d'inclure ceux du voisinage d'une part... et de limiter les risques d'interception de la clef de chiffrement échangée à ce moment d'autre part, pour les inclusions sécurisées). C'est assez pratique, à condition d'avoir suivi le tuto pour rendre persistant le /dev/ttyUSB alloué à la clef (cf wiki).
Le seul truc que je trouve ballot, c'est que le soft permettant de sauvegarder la config z-wave de la clef (=> en cas de défaillance, pas à tout ré-inclure: On rachète la même et in restore la config) n'existe que sous windows.
Pour ce qui est de dlink, je découvre qu'ils font du z-wave... A regarder dans le répertoire contenant les fichiers de description des périphériques d'open z-wave, on a ceux-ci:
Code : Tout sélectionner
~/domoticz/Config/dlink $ ls
dch-z110.xml dch-z120.xml dch-z510.xml
Par contre, aucune idée du niveau de support réel... A lire le fichier du z510:
Code : Tout sélectionner
~/domoticz/Config/dlink $ cat dch-z510.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- D-Link: DCH-Z510 Siren -->
<Product xmlns="http://code.google.com/p/open-zwave/">
<!-- Configuration Parameters -->
<CommandClass id="112">
<Value type="byte" index="7" genre="config" label="Customer Function" min="0" max="127" value="0">
<Help>
Bit 0: Reserved
Bit 1: Reserved
Bit 2: Reserved
Bit 3: Reserved
Bit 4: Notification type (0: Using Notification Report, 1: Using sensor Binary Report).
Bit 5: Reserved
Bit 6: Reserved
Bit 7: Reserved
</Help>
</Value>
<Value type="list" index="29" genre="config" label="Disable Alarm" units="" min="0" max="1" value="0" size="1">
<Help>
Disable the alarm function.
0: Enable Alarm, 1:Disable Alarm,
Caution: After the power up, this configuration always be 0.
</Help>
<Item label="Enable Alarm" value="0" />
<Item label="Disable Alarm" value="1" />
</Value>
<Value type="byte" index="31" genre="config" label="31. Alarm Duration" units="30 sec" min="0" max="12" value="6">
<Help>
Play alarm sound duration.
1 tick is 30 second. Default is 3 minutes, maximum is 63.5 minutes.
0: means never auto stop
</Help>
</Value>
</CommandClass>
<!-- Basic set as report -->
<!-- <CommandClass id="32" setasreport="true" ignoremapping="true"/> -->
<!-- Association Groups -->
<CommandClass id="133">
<Associations num_groups="1">
<Group index="1" max_associations="8" label="Lifeline"/>
</Associations>
</CommandClass>
</Product>
Il semble n'y avoir que 2 paramètres de config implémentés. Voir avec la doc, si c'est détaillé, afin de vérifier que c'est complet. Si la doc dlink ne détaille pas, les infos sont parfois présentes sur le site de la z-wave alliance pour les produits qui y ont été envoyés en certification.
Mais a première vue, au moins, ça semble OK au moins pour un support minimal des 3 équipements connus. A noter qu'il peut y en avoir d'autres d'ajoutés depuis la dernière stable de Domoticz car c'est sur celle là que je suis.
Pour des fonctions alarme en plus de domotique, attention a mettre le PI et la box sous une alim secourue.
Pour ma part, le PI3 est installé avec une raspbian minimale (sans interface graphique, donc sans utilisation du GPU qui consomme pas mal ; de toutes manières comme il est administré en ligne de commande via ssh c'est pas un problème) et le 5V USB de ma box suffit dans ces conditions à l'alimenter. J'ai donc acheté 20€ sur aliexpress une batterie UPS 12V à intercaler entre le transfo de la box (livebox play alimentée en 12v) et cette dernière. Ce qui assure donc l'alime secourue pour la bix et le PI qu'elle alimente en 5V via l'USB.
Note que pour résoudre le problème des images des "visiteurs", je compte pour ma part sur un compte mail google spécifique domotique. Les caméras envoient les images des captures de mouvement vers un FTP hébergé par le PI, ce dernier ayant un service écrit en python qui check par tranche de 10s si des captures sont reçues et dans ce cas les place dans une archive (chiffrée avec mot de passe, que google n'ait pas des images de chez moi) et les envoie par mail.
En présence, les envois ne sont faits que de nuit pour les caméras extérieures du compte mail dédié vers ce dernier seulement. En absence, toutes sont envoyées vers le compte dédié et mon adresse habituelle.
Ainsi, même un malin qui sera parti avec le PI sous le bras et aura su lire mes scripts pour récupérer les login du compte gmail dédié afin d'aller effacer ses images ne pourra pas accéder au second compte.
Et pas de pb de NAS potentiellement volé avec les images.
En plus, ce service permet aussi de remonter des états de capture de mouvement dans domoticz, en utilisant une fonctionnalité intéressante de ce dernier: Les switch virtuels (dummy). Ce qui permet de se faire un PIR virtuel, dont l’état est controlé par le script via l'API http de domoticz.
Pas si simple à faire (surtout que la detection de mvt via caméras ne doit pas se déclencher pour le chat qui passe ou la luminosité qui varie, mais si qqun commence à bricoler une entrée plus de 30s), mais puissant... et économique: On peut ainsi intégrer ses PIR virtuels dans ses scripts d'alarme utilisant de vrais capteurs de manière assez transparente.
Autre fonctionnalité: Cela gère aussi en présence des notifications vocales (synthèse vocale via espeak) qui disent de vive voix ou cela bouge... vu que certains n'hésitent parfois pas à rentrer même si les gens sont là car on ne peut avoir l'oeuil partout...