Mini keypad zipato

[Rvitch]

Si le badge remonte c'est qu'il n'est pas enregistré et c'est aussi pour ça que tu ne passe pas à 5.
Il n'y a pas de remonté du dernier badge, à partir du moment où le badge est enregistré, au passage il bascule à 5 mais ne s'affiche pas comme passé et c'est d'ailleurs balo.

Envoyé de mon MI 5 en utilisant Tapatalk

[mike67]

Bonjour

La déclaration des badges doit toujours se faire via l'enrollement code ou le bug de l'assistant est réglé?

Merci

[Rvitch]

Il me semble que le bug est règlé mais tu peux quoi qu'il en soit configurer les codes manuellement.
Il te suffit de passer le badge, de copier le code remonté et de le mettre dans un endroit mémoire via paramètres du module.
Normalement après ça quand tu passe le badge qui est enregistré, il ne remonte plus la valeur du badge mais bascule la valeur de 5 à 6ou l'inverse.

Envoyé de mon MI 5 en utilisant Tapatalk

[rodfred]

Y a t'il moyen de connaitre le badge qui a été détecté?
pour avoir différents scénario suivant qui badge

[Anonyme]

Contenu supprimé à la demande de son auteur

[mike67]

Et pourtant on voit bien le code du dernier badge passé et du coup peut être qu'on peut l'associer à un nom via un virtuel ou un script ?

Dans mon cas par contre c'est bizarre, j'ai 2 badges et c'est le même code qui remonte

[Anonyme]

Contenu supprimé à la demande de son auteur

[Rvitch]

Si j'ai bien compris quand j'en ai discuté avec nerchy, la fonctionnalité est inclue dans la version bêta de la librairie.
Il reste à attendre que cette bêta bascule en stable et soit intégrée à jeedom.
J'ai bon ?

Envoyé de mon MI 5 en utilisant Tapatalk

[Talon Libre]

Il semble que l'assistant pour la gestion des badges qui était jusque là en beta soit arrivé en version stable avec la maj du plugin Openzwave de ce matin, si j'en crois le changelog (https://github.com/jeedom/plugin-openzw ... g.asciidoc) :

Bug Fixes
[...]
Assistant de gestion des badges pour les lecteurs RFID.
[...]

C'est en cours d'installation chez moi...

Stéphane

[Rvitch]

Je n'ai pas encore updaté mais d'après les retours de l'équipe, je ne pense pas que la gestion des badges soit la..

Envoyé de mon MI 5 en utilisant Tapatalk

[Bosquetia]

Je n'ai pas encore updaté mais d'après les retours de l'équipe, je ne pense pas que la gestion des badges soit la..

Envoyé de mon MI 5 en utilisant Tapatalk

Les retours de l'équipe ??

[Rvitch]

Je te cite :

Hello

Il y a strictement aucune modification importante.
C'est principalement une dernière MAJ pour des nouvelles configurations de modules

Et également l'intégration du pack d'icone de modules sur fond transparent fait par un membre du forum romanais

Envoyé de mon MI 5 en utilisant Tapatalk

[Talon Libre]

Bon, alors après avoir changé les piles (!), refait l'association pour être en direct avec le contrôleur sans passer par 124 sauts, j'ai bien réussi à associer des tags avec l'assistant sans aucun problème !

J'ai juste eu un problème de scénario car j'utilisais le code au lieu de l'action dans les tests (oui, je sais...).

Bref, tout bien, merci aux devs !

[gabortoulouse]

Bonjour à tous !

J'ai enfin fini de lire les 16 pages de ce post. J'ai appris beaucoup de choses, merci à tous.

Hélas, je n'ai toujours pas réussi à résoudre mon problème.

Mon problème est double :
1 - Lorsque je badge, mon Jeedom ne reçoit l'information qu'au bout de 4 ou 5 minutes (durée variable à quelques minutes près). Pourquoi faut-il autant de temps pour que le Keypad envoie l'information ?
2 - Et alors, quand jeedom reçoit l'information, il déclenche le scénario (sur changement de "Action") par 3 fois, avec 2 minutes d'intervalle entre chaque fois. Je suppose que c'est le Keypad qui envoie l'information 3 fois. Pourquoi 3 fois ? Et pourquoi à 2 minutes d'intervalle entre ces 3 fois ?

J'avoue que je ne sais plus quoi faire, sachant que cela fonctionnait bien jusque vers avril/mai : j'avais une réaction immédiate de Jeedom qui recevait les actions de badge de manière instantanée. J'avoue que je commence à me dire qu'il y a un problème sur le Keypad Zipato.

Voici ma config :
Jeedom complètement à jour sur RPI + clé Z-Wave Sigma Designs
Le Keypad est parfaitement reconnu, j'arrive sans problème à ajouter / retirer des tags, le Keypad répond parfaitement.
Il est en lien direct avec la clé Z-Wave

Voici tout ce que j'ai donc pu tenter :
Exclure/inclure le keypad des dizaines de fois.
Détruire/refaire les commandes du Keypad
Mettre les commandes Action et Code en "Toujours répéter", "Jamais répéter" ou "Automatique"
Redémarrer le réseau Z-Wave
Réinstaller Z-Wave dans la config du plugin Z-Wave
Redémarrer totalement le RPI environ 12000 fois (!!!)
Bien vérifier que le keypad est en lien direct avec le contrôleur


Avez-vous une idée de ce que je pourrais tenter SVP ?


A ce jour, je cherche à le réinitialiser totalement, mais je ne sais pas comment faire. La doc à ce niveau reste un peu incompréhensible :
RESET [...]
This function can be activated by sending a configuration set frame:
CONFIGURATION_SET
PARAMETER: 0x01
SIZE: 0x01 (can’t be different from 1)
VALUE: 0xFF (can be any value except for 0x55)


Merci à toute personne qui aurait une idée. Je pourrais mettre des logs aussi au besoin, mais très honnêtement, ils n'apportent pas grand chose de plus...


Merci merci merci !!!

[Rvitch]

Salut,
Je suis loin d'être un Expert en zwave, mais j'aime bien les casses tête..alors je te propose d'essayer de t'aider.
Si je résume tes soucis:
-Le statut (sous jeedom) à une grosse latence.
-Le scénario (qui a fonctionné) a un comportement erratique, et surtout, non conforme.

Tu parle de résultat sur scénario, mais comment se comporte le module, est ce lui qui n'envoie pas son statut ou le scénario qui réagit bizarrement?
Si tu vérifie le statut de l'info du module, il bascule de 5 à 6,et l'inverse, ou pas ?
Tu peux donc déjà vérifié si c'est le module qui ne fait pas où mal son taf ou si c'est au niveau du traitement de l'information dans le scénario que ça cloche.



Envoyé de mon MI 5 en utilisant Tapatalk

[gabortoulouse]

Salut Rvitch,

D'abord, je te remercie de m'aider.

Je précise que la latence n'est que pour le keypad. Je n'ai aucun autre soucis avec mes autres modules Z-Wave (j'en ai une vingtaine).

La bascule entre 5 et 6 se fait parfaitement, l'information étant toujours envoyée avec beaucoup de retard et 3 fois avec un écart de 2 minutes entre chaque fois.

Concernant le résultat sur scénario, je ne sais pas exactement ce qui provoque le problème : est-ce que c'est le Keypad qui renvoie l'information de badgeage, ou est-ce que c'est Jeedom qui foire ? Très honnêtement, je n'ai aucun soucis sur aucun autre scénario. J'ai aussi refait totalement le scénario au cas où. Je pense réellement que c'est le Keypad qui envoie l'information en retard et qui plus est 3 fois avec 2 minutes d'intervalle.

Je viens de refaire une exclusion/inclusion et je me rends compte que j'avais mis de côté un phénomène étrange : le module est détecté par Z-Wave 3 fois de suite ... à 2 minutes d'intervalle !!
En gros, j'inclus mon Keypad qui n'est détecté qu'au bout de quelques minutes puis redétecté 2 fois de suite avec 2 minutes d'intervalle...

J'ai donc l'impression que ce n'est pas que l'événement action qui est envoyé 3 fois, mais la détection du module aussi !

Qu'est-ce que je dois incriminer ? Un plantage de Z-wave ou le Keypad qui est devenu un peu fou ? Je pense aussi à un soucis de Keypad fantôme dans la base de données de Jeedom/Z-Wave.

Une idée de ce que je peux aller voir ? Je vais refaire la manipulation et donner le log Z-Wave.

[gabortoulouse]

Bon, après avoir refait la manip, je regarde le log Z-Wave et j'ai cette erreur :

Code : Tout sélectionner

[2017-12-17 20:03:56][ERROR] : Error on send request to jeedom HTTPConnectionPool(host='127.0.0.1', port=80): Read timed out. (read timeout=120) retry : 0/3
[2017-12-17 20:05:56][ERROR] : Error on send request to jeedom HTTPConnectionPool(host='127.0.0.1', port=80): Read timed out. (read timeout=120) retry : 1/3
[2017-12-17 20:07:56][ERROR] : Error on send request to jeedom HTTPConnectionPool(host='127.0.0.1', port=80): Read timed out. (read timeout=120) retry : 2/3
[2017-12-17 20:07:56][ERROR] : Critical error on  send_changes_async local variable 'r' referenced before assignment

En regardant sur le Net, je vois que c'est un problème dans Python. Et je vois aussi que l'intervalle entre les 3 Retry du log est de 2 minutes...
Ca ne doit pas être un hasard : 3 tentatives et 2 minutes d'écart entre chacune... Ca me rappelle quelque chose !!
Je réinstalle Python...

[EDIT]
Python a été réinstallé. J'ai fait comme ça :

Code : Tout sélectionner

sudo apt-get remove python3
sudo apt-get install python3
sudo apt-get install python3-pip

Mais j'ai toujours le message d'erreur dans le log de Z-Wave.
J'ai un RPI avec DEBIAN, comment dois-je faire pour installer une version précédente de Python ? Je suis une bille en Linux...

Merci !!

[sa77]

Bonsoir à tous,
mon clavier zipato fonctionne bien avec les badges. Il est couplé au plugin alarme. Lorsque je passe un badge pour activer ou désactiver, je vois bien dans le dashboard le changement d'état au niveau du plugin Alarme.
En revanche quand le veux activer/désactiver l'alarme depuis le dashboard avec le widget du plugin Alarme, il n'y a pas de changement au niveau du clavier Zipato/ L'état reste à 5 ou 6.
Comment fait-on pour pour modifier cet état ?

J'ai du oublier quelque chose...

[sa77]

Au final c'est pas bien grave puisque l'alarme est gérée depuis le plugin Alarme. Mais je voulais savoir s'il existe une commande action pour modifier l'état du clavier Zipato.

[robing82]

Pourquoi veux-tu modifier l’état du clavier? Tu ne peux pas faire ça. L’équipement Clavier que tu as créé sous Jeedom représente l’état de ton clavier. Seul des interactions sur celui-ci le modifiera.
C’est comme si tu voulais modifier l’état d’un capteur de mouvement. Ça n’a pas de sens.