un projet peut être pas si Trankil que ça !

[trankil]

@magicgg91: il est en effet dommage que les solutions domotiques ne s'attachent pas plus à masquer totalement ces particularités et à rendre la vie vraiment plus facile pour Monsieur Tout le monde.

[Laco]

Salut trankil,

Nikel tes explications
Par contre, je ne veux pas te donner du travail supplémentaire car tu passes déjà beaucoup de temps à aider un peu tout le monde sur le forum, y compris moi et je t'en remercie
mais je pense que cette explication serait bien dans un wiki , idem pour celle-ci lien.
Ça serait vraiment dommage quelles passent aux oubliettes avec le temps

[trankil]

(PS: étant opposé au Wiki, sur la forme et le fond actuels, il ne faut malheureusement pas compter sur moi pour y apporter ma contribution active)

[Didier43]

Personnellement une fois que j'ai bien "dressé" mon module Zwave sur pile, je privilégie des"wake up" très élevé (3 ou 4h).
J'ai noté la mise en place de chaque module, je vous ferez un retour sur la consommation des piles dans très longtemps, je l’espère .

[Laco]

Ça serait également ma philosophie.
Une fois que tout est bon, on ne touche pas à quelque chose qui marche

[toregreb]

Moi, j'ai un temps de wakeup plutôt long et quand ma femme me demande quelque chose, il me faut toujours un peu de temps pour le faire. C'est d'ailleurs ce qu'elle me reproche, et j'ai beau lui expliquer que c'est pour économiser mes batteries, elle a du mal à comprendre.
Lorsque je recevrai mon "oeil", je le configurerai pour fonctionner un peu comme moi : toujours à l'écoute mais souvent endormi pour s'économiser.
Peut-être comprendra t-elle mieux à ce moment là....

[trankil]

[Laco]

Je la ressortirai celle la

[florent306]

merci pour l'explication!.
voici l'image de mes route comme tu l'a expliqué. est ce que c'est ok ainsi? je supprimerais l'image après si tu veux...
edit: de plus je me suis rendu compte qu'une de mes pris était incomplète, j'ai refais l'interview.(justement ce module était capricieux...) je vais voir si ça marche mieux maintenant!. encore merci.
edit: image sur mon post florent306

[trankil]

@Florent306:
Les points positifs:
1. c'est symétrique , ce qui favorise le même chemin à l'aller qu'au retour, gage de déterminisme

les points négatifs ou à améliorer:
1. ton device 2 n'a pas de route directe avec ton razberry (mais la case est verte, donc reste dans les bons critères de qualité)
2. les cases en jaune ne sont pas super et montrent l'utilisation de chemins indirects (maillage zwave).

[florent306]

trankil je poste sur ma page pour pas trop charger la tienne.

[bercavibe]

@Trankil, puis-je te suggérer ta prochaine contribution de vulgarisation théorique et pratique "Learnmyself by Trankil" ? : Les variables dans les scénarii.
C'est un grand mystère pour les non-développeurs, dont je fais partie...

A quoi servent-elles? Quelles sont les différents types de variables ? Comment les utiliser ? Quels avantages ? Quelques exemples simples, tips and tricks, etc.
(j'ai plein d'autres sujets en réserve si besoin )
Merci par avance.

[trankil]

@bercavibe: j'aime bien ton "learnmyself" qui se rapproche de mon "learntofish"

Alors j'apprécie ta suggestion mais malheureusement, je ne ferai pas de sujet concernant les variables (du moins pas pour l'instant) car ça concerne l'utilisation d'une fonction "utilisateur" native de Jeedom, sujette à modification et à évolution (de façon plus ou moins annoncée).
Or lorsque je propose des bouts de code ou "tutos" sur mon sujet, je le fais dans une optique de pérénité et de reproductibilité. Sauf exception, ce sont des informations qui ne changeront pas et resteront toujours valables. Alors que là, il suffit d'une simple modification de l'interface pour rendre un éventuel "tuto" incorrect. De même si la syntaxe change.

Par ailleurs, de nombreux scénarios ont déjà été publiés sur le forum montrant l'utilisation de ces variables et il suffirait qu'un modérateur les regroupe dans un espace de documentation quelconque pour contenter tout le monde je pense (en n'oubliant pas bien sûr d'expliquer didactiquement le pourquoi de telle ou telle action/bloc/variable).

Enfin, dernière raison, comme il s'agit d'une fonction native de Jeedom, j'estime que ce travail de documentation et de vulgarisation propre à Jeedom incombe intégralement à l'équipe en charge de cette solution.

[Didier43]

Je reviens avec mon module dead : J'ai donc forcé la mise à jour des route, et miracle, le module est revenu à la vie !
Depuis il fonctionne.

Ton post est tombé à pic

[trankil]

nickel.

[mgo]

si par contre Trankil, pouvais éclaircir le notion de groupe dans Zwawe cela me ravirait

[trankil]

@mgo: ce lien n'est il pas suffisant pour comprendre la notion de groupe / association ?

[mgo]

OK merci

je croyais que cela avait un rapport avec le routage

[trankil]

non, pas du tout.
En fait la notion de Groupe (et d'association) définit à qui le module zwave va envoyer ses messages. (en provenance de ses capteurs ou du retour d'état zwave)

Cette fonction est essentielle si tu souhaites une bonne réactivité et s'oppose à la notion de "wakeup", qui ne concerne quant à elle que les messages en provenance du Razberry.

Tous les modules n'ont pas les mêmes capacités et ne disposent donc pas du même nombre de groupe. Cela est systématiquement précisé sur leur notice, ainsi que la signification de ces groupes. Il est également possible de visualiser ces possibilités sur le site: http://www.pepper1.net/zwavedb

J'ajoute que la fonction de Groupe est la plus importante pour avoir une bonne installation zwave, et éviter de configurer des cron de polling à tout va sur son serveur Jeedom.

[ddjaff33]

Ton explication sur les routes et le fonctionnement général du ZWAVE est très intéressante. J'ai du travail à ce que je vois.

Je commence par un petit 'Request NIF for all device' et attend donc le wakeup le + éloigné avant de forcer la mise à jour des routes.

Suis quand même étonné par le fait d'avoir autant de jaune et surtout de rouge.