J'ai mis le feu chez moi 🔥 ... pour essayer!

[guipom]

Bonjour,

Suite à ma migration zwavejs j’ai mis le feu, pour de vrai mais évidemment dans un environnement contrôlé, pour vérifier le bon foncitonnement de mes capteurs de fumée face à une vraie fumée.

J’avoue que j’en ai pris plein les oreilles, mais pas à cause de jeedom … le scénario n’a pas eu le temps de se déclencher.

Une fois la fumée détectée par un détecteur Fibaro (FGSD002) j’ai eu la sirène qui s’est déclenchée et les autres détecteurs aussi, avec en plus deux prises connectées qui se sont éteintes.

Ce n’était pas vraiment ce à quoi je m’attendais, normalement c’est Jeedom qui prend la main dans ce cas de figure, mais ici c’est zwave qui déclenche les actions. Donc probablement que la communication fonctionne bien mieux qu’avec openzwave, mais comment desactiver par exemple l’extinction des prises ou la sirène ?

C’est pas censé être lié aux groupes ? Je pensais qu’il fallait des associations explicites pour que ce soit en place ce genre de communication directe !

Groupes de la prise

Configuration du module Smoke Detector (paramètre 13 surtout)

J’ai probablement raté un truc, mais j’ai un comportement que je comprends, mais auquel je ne m’attendais pas! si vous avez une idée de ce qu’il faudrait que je vérifie comme réglage !

[Nicoca-ine]

Salut
J’avoue être perdu sur cette partie de zwavejs par rapport aux associations sous openzwave. les réponses m’intéresse, n’ayant pas trouvé d’info la dessus pour l’instant.

[mangles]

Pour suivre. J’aimerais bien comprendre également le bon fonctionnement des associations

[arnog23]

Bonsoir,

Le Broascast (Paramètre 13) fonctionne sans avoir besoin d’association. C’est le principe du Broadcast d’envoyer à tout le monde. Ensuite, ceux qui le recoivent le prenne en compte ou pas suivant leur configuration.

Plus de détails sur le blog de Nechry :

Alarm broadcast quèsaco? - La domotique de Nechry

[SWR]

Également preneur

[guipom]

Oui c’est ce que j’indique dans mon message initial.
Le problème c’est que je ne sais pas si c’est un réglage qui peut se faire globalement ou par module, si je le fais par module, je sais que certains modules n’ont pas de réglage pour ne pas réagir à un broadcast, du coup il faut que je m’assure qu’aucun broadcast ne soit opérant, donc passer sur les modules qui pourraient éventuellement en emettre.

Bref, je cherche surtout une bonne pratique pour gérer ça au mieux. Si je laisse par défaut, le comportement est le plus sécurisant possible, mais je n’ai la main sur rien et c’est trop problématique.

[arnog23]

Je n’ai rien vu à ma connaissance qui permette de configurer cela de façon globale d’autant plus que certains modules le gère et pas d’autre. La seule solution que je vois est de passer manuellement sur l’ensemble des modules pour s’assurer que l’émission est désactivée sur les émetteurs et les réactions désactivées sur les récepteurs.

En ce qui me concerne, j’ai désactivé toutes ces configurations liées au Braodcast pour, comme tu le dis, maitriser ce qui est fait et ne pas laisser Zwave faire cela.

Mais ça pourrait être intéressant en effet que le nouveau plugin soit en mesure d’indiquer si un module gère le Broadcast en émission et/ou réception. Néanmoins, il ne semble pas s’agir d’une classe remontée par les modules (je me trompe peut être mais je n’ai pas trouvé de classe correspondante dans les spécifications de la Zwave Alliance) qui permettrait de faire cela de façon plus ou automatique mais d’un ou plusieurs paramètre(s) de configurations. Cela demanderait donc probablement un gros travail pour lister les modules « compatibles ».
Ou alors peut être faire une demande directement côté ZwaveJS.

[Bison]

Salut,

Je ne sais pas si ça peut faire avancer l’affaire mais coté Zwave-JS (pas plugin que je n’ai pas) on peut configurer les broadcast suivant si le matériel le gère ou pas.

Exemple sur capteur de fumée Fibaro (broadcast inactif par défaut) :

Et donc ajouter le module à des groupes :

[guipom]

oui, justement, c’est ce que je demande.
Faut il aller modifier la configuration de chaque module qui pourrait potentiellement émettre un broadcast, faut il desactiver les modules qui réagissent à un broadcast, ou un mix des deux, sans trop impacter son installation zwave.

Je ne sais pas si le broadcast est retransmis, je ne pense pas, mais suivant ou le feu se déclare chez moi, soit la sirène sonne, soit elle ne sonne pas, les détecteurs de fumée voisins réagissent, ou pas. Ca peut être intéressant pour réagir plus vite, mais les actions par défaut comme couper les prises de courant ne sont pas appropriées. Et je ne voudrais pas pourrir la configuration de mes modules en partant sur une mauvaise compréhension.

Donc oui, une option serait d’aller dans tous les modules qui détectent (fumée, inondation …) et leur dire de ne plus faire de broadcast du tout. Et je continue de tout gérer dans Jeedom.

[Bison]

@guipom

Faut il aller modifier la configuration de chaque module qui pourrait potentiellement émettre un broadcast,

Alors oui clairement pour moi, que ce soit avec OpenZwave ou maintenant avec Zwave-JS le comportement de broadcast est propre à chaque module et il faut lui indiquer le comportement qu’il doit avoir à ce sujet.

[Ludi]

Hello Guipom,

Merci pour ce test réel ^^
J’ai une question concernant l’info « chaleur », est-ce qu’elle est en 0 ou 1 ou c’est une température? Car dans les commandes c’est indiqué 0 ou 1 mais c’est pourtant une info numérique.
Est-ce que cela a détecté de la chaleur avant ou après la fumée?

[guipom]

Désolé, je ne sais pas!
J’ai bien chaleur qui est intégré dans jeedom mais lors de mon test c’est le broadcast qui a pris la main en quelques secondes. Et donc jeedom n’a pas été informé du maintien de chaleur, il faut qu’il reste à l’état 1 pendant 30s pour que ce soit pris en compte.
Donc aucune idée !