Finir l'intégration du détecteur OWON PIR313-E

Voila ce que je propose

image

image

J’ai laissé les textes par défaut pour la feature Tampe (actif/inatif) sauf que je trouve que cela ne colle pas. Si vous avez une idée je suis preneur

@_Will_71 : merci.
Serait-il possible néanmoins de changer les couleurs pour la batterie faible : rouge pour « oui » et vert pour « non ».

Pour l’autoprotection, je ne sais pas trop non plus. Peut-être « verrouillé » « déverrouillé » ?
Ou alors, au lieu de « Autoprotection » mettre « Verrouillé sur support » ou « Verrouillé », ou « En place sur support », ou « En place » :face_with_spiral_eyes: et les valeurs « oui » (en vert) et « non » (en rouge).

Ok pour les couleurs de la batterie.

Pour autoprotection je réfléchis ce qui rend le mieux et je proposerai autre chose.

Peut-être « Intégrité du capteur » ?

Pourquoi pas. Après le nom de la fonction reste personnalisable dans Gladys.
Sinon je pense à un nom similaire au capteur de mouvement.
Détection de vandalisme (oui/non)

En regardant tous les cas ou ce terme est utilisé cela fait plus penser à équipement sensible dans le sens dont on surveille qu’il soit fonctionnel (alimentation, vandalisme, perturbation externe), c’est vrai que « tamper » c’est plus un terme générique dans ce cas, peut-être « Détection d’altération »

image

Dans mon système d’alarme, c’est ‹ sabotage ›

image

image

Voila ce que j’ai fait. Après le nom reste personnalisable

@pierre-gilles , la PR

2 « J'aime »

Merci ! ça a été testé en réel ?

Il va y avoir un petit conflit avec la PR de @Lokkye sur les alertes de batterie.

Suivant la PR que je merge en premier, il y aura des modifications à faire par l’autre dans sa PR.

Comme la PR de @Lokkye est antérieur et quasi prête, je lui donne la primeur mais du coup @_Will_71 ta PR devra être modifiée pour prendre en compte ces changements dans les alertes de batterie (vu que tu ajoute un type « low battery » qui est dans la category « battery »)

J’ai pas testé avec un vrai capteur, seulement en mqtt en envoyant moi même des messages mqtt.
Je peux toujours faire une image docker pour que quelqu’un test en réel.

Pas de soucis merge la PR @Lokkye et je modifierai ma PR ensuite.

2 « J'aime »

L’image en cours de création dispo dans environ 40min
willde71/gladys-test:zigbee2mqtt-owon-pir313-e

Vu que j’ai le capteur en question je veux bien tester. Mais il faut m’expliquer comment faire.

@bab85, tu as tout expliqué sur ce tuto :

Merci @Tlse-vins .
@_Will_71 J’ai donc fait un test :

  • Pour la batterie c’est ok, l’item apparait, et pour des piles usagées on a bien batterie faible : oui en rouge, et pour des piles neuves : non en vert.

  • Par contre, l’item du tamper n’apparait pas dans la liste des propriétés de l’appareil.
    Et pour info : la traduction de tamper qui est faite dans le tableau de bord de z2m c’est « manipulation » avec comme valeur « non » et « manipulé ». Mais c’est juste une info, « détection sabotage » me va.

Comme une attention se posait concernant la gestion de la batterie entre deux versions de développement, j’ai ajouté un détecteur de mouvement sonoff. Sur la partie en prod, seul la propriété du niveau de la batterie est proposée. Dans le test que j’ai fait, il y a les deux : niveau et batterie faible (oui non). Cela m’indique un niveau à 100% et batterie faible « non » en vert. Donc les deux semblent cohabiter correctement. Je dis « semble » car je ne sais pas comment se comporte la propriété « batterie faible » quand la pile est usée (car je n’en ai pas sous le coude).

Je te remercie pour le test.

Ok pour la batterie.

Dans le cas de ton capteur c’est normal que tu as maintenant les 2 dans le test car les 2 exposes (battery et battery_low) sont disponibles pour ce capteur

Concernant l’expose pour le tamper je vais regarder.

Dans tous les cas il faudra attendre que la PR de @Lokkye soit merge pour que je puisse mettre a jour le code de mon côté.

Je viens de la merge ! :smiley:

2 « J'aime »

@bab85 ,

Une question par contre concernant l’installation que tu as fait.
Tu as gardé la même base de donnée que ta prod avec le capteur déjà appairé où cette une installation de test avec nouvelle base de donnée avec nouveau conteneur zigbee2mqtt et tu as re-appairé ton capteur owon?

J’ai laissé l’information de la base telle que dans le tuto (SQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-production.db ), donc base de prod me semble-t-il. Par contre il a quand même fallu que je ré-appaire les capteurs. Je sais pas si c’est normal (c’est vrai qu’utilisant la base de prod, je m’attendais à avoir déjà mes capteurs reconnus). Dans z2m il n’y avait plus rien.

Le fait que tu me poses la questions je viens de faire une vérif. Je me rends compte que j’ai du faire une boulette :face_with_open_eyes_and_hand_over_mouth:, car je pensais que j’avais deux base z2m et non, quand je reviens sur mon gladys de prod, j’ai le même z2m avec seulement les 2 capteurs que je viens de tester, et j’ai une croix rouge entre Gladys et MQTT dans la configuration.
Je vais attendre de finir les tests pour ton développement, et je me remettrais propre ensuite.

Quel nom as tu donné pour le dossier qui contient la base et config?
image

Peux-tu aller dans la page de zigbee2mqtt et faire une capture d’écran de l’onglet Etat pour que je puisse voir tous les exposes de ton capteur?

Ci dessous un exemple.

Pour le nom du dossier j’ai du mettre /var/lib/gladysassistant_OWON_test: /var/lib/gladysassistant\

Et pour l’état voici :
image